,0CT-25-1934  11:16  DTIC-BR 

I  REPORT  DOCUMENTATIQM^aysc 


703  274  9307  P.02/^ 


i.  AGU,iT!r^t  ONLY  ^Uk)  ‘'TT-^pOBT  t^fi - —XT- - 

prKEPORTTYpf 

4.  TITLE  AND  suarnrii  - - — i  Spnfpin]-^p|-  ^99^  « 

"^“Sineerlng  Process  Model 

^  AUTHOR(S)  - - —  ■  _ 


A>/ot  /ypprov^cf 
OMa  No.  oro^jas 


— — _  •  tw/, 

3.  REPORT  lYPE  AND  OATES  COVERED 


I S.  FUNDING  NUMBERS 


Ms  Tamra  Moore,  editor 

ORWVNUAIION  HAME(5i  AND  ADDReSS(5) 

DISA/JIEO/  C/=-SiO  ^ 

701  South  Courthouse  Road  lio 
Arlington,  Va  2220<f-2199  ^ 

».  «'ONSOIUNG/«,ur«,QHlNG  AGtNC^  NAMe(S)  AND  A^fl 
same  as  above 


^EI-ECTE 

^  JAM  2  419®^' 


FPWrowwiNGORGANKATiON" 

S  RETORT  NUMBER 


- — AGENCy  REPORT  NUMBER 


1.  A.  -s 

IZ*.  OISTOBUTTON/AVAlLABtrrY  STa'temENT  . .  . 


I iS.  DISTRUIUTION  CODE* 


Available  for  public  distribution  unlimited 


This  document  describes  cr^-F,. 

Process  Model,  Version  2  0  Reengineering 

Model  compose  the  so??„ar^reSj,-  described  in  She 

Define  Project,  Reverse  Encri Process,  including 
Model  is  represented  using^the  Engineer.  The 

The  intended  audience  for  the  Moder.’^''  Modeling  technique. 

DoD  tasked  to  reengineer  an  i  rs  any  organization  within 

The  Model  can  be  obtained  from  the  Defin^°^^i°^  system  (AIS)  . 
Center,  (703)  274-7633.  ^  Defense  Technical  Information 


reengineering,  reverse  engineering,  softwarp  ps.  number  of  pages 

engineering,  maintenance.  IDF.F  ^ottware 

— _ -  _ _  le.  PRICE  CODE  "  ~ 

VisN  7’;/inlni  -toA  .  I  ■  ,,  I 


^ndard  Form  298  (Rev.  2-89) 

tv  ANSI  Sid.  Qj-18  ' 


99501 23  092 


Defense  Information  Systems  Agency 
Joint  Interoperability  and  Engineering  Organization 
Center  for  Software 

701  South  Courthouse  Road;  Arlington,  VA  22204-21 99 


Software  Systems  Reengineering 
Process  Modei 


VERSION  2.0 


September  1994 


Prepared  by: 

Software  Systems  Engineering  Department 
Software  Engineering  Technology  Division 


ACKNOWLEDGEMENT 


This  document  was  prepared  by  the  Defense  Information  Systems  Agency,  Joint 
Interoperability  and  Engineering  Organization  (DISA/JIEO),  Center  for  Software'  (CFSW) 
sponsored  by  the  Office  of  the  Assistant  Secretary  of  Defense  (OASD)  for  Command, 
Control,  Communications,  and  Intelligence  (C^I).  The  Center's  Software  Systems  Engineering 
Department  would  like  to  thank  the  participants  in  the  Software  Systems  Reengineering 
Process  Model  Technical  Review  for  their  contribution  to  the  development  of  the  Software 
Systems  Reengineering  Process  Model,  Version  2.0,  September  1994.  Representatives  from 
the  Department  of  Defense  and  Federally  Funded  Research  and  Development  Centers 
(FFRDCs)  met  and  reached  consensus  on  the  software  reengineering  process  during  this 
Technical  Review  held  June  14-17,  1994.  This  consensus  software  reengineering  process  is 
captured  in  Version  2.0  of  the  Model  as  defined  in  this  document.  The  Model  is  represented 
both  graphically  and  textually  and  is  intended  for  use  by  all  DoD  in  planning  and 
implementing  software  reengineering  of  automated  information  systems.  The  participants 
attending  the  Technical  Review  represented  the  following  organizations; 

Defense  Finance  and  Accounting  Services; 

-  Financial  Systems  Activity,  Columbus,  Oh 

-  Financial  Systems  Activity,  Denver,  Co 

-  Financial  Systems  Organization,  Indianapolis,  In 

Defense  Information  Systems  Agency,  Joint  Interoperability  and  Engineering 

Organization; 

-  Center  for  Standards,  Reston,  Va 

-  Center  for  Software,  Arlington,  Va; 

-  Center  for  FPl  Expertise 

-  Planning  and  Integration  Directorate 

-  Software  Reuse  Program 

-  Software  Process  Improvement  Program 

-  Software  Reengineering  Program 

Defense  Logistics  Agency,  Service  Activity  Center,  Columbus,  Oh 


^The  Center  for  Software  includes  the  organization  formerly  named  the  Center  for 
Information  Management  in  the  Defense  Information  Systems  Agency's  Joint  Interoperability  and 
Engineering  Organization. 


Department  of  the  Air  Force: 

-  Air  Force  Military  Personnel  Center,  Randolph  AFB,  Tx 

-  HQ  CSC/SDQ,  Tinker  AFB,  Ok 

-  MSC/SOE,  Hill  AFB,  Ut 

-  USAF  Software  Technology  Support  Center,  Hill  AFB,  Ut 

-  USAF  Standard  Systems  Center  (SAC/EN),  Maxwell  AFB-Gunter  Annex,  A1 

Department  of  the  Army: 

-  U.S.  Army  Information  Systems  Software  Center,  Fort  Belvoir,  Va 

-  U.S.  Army  Information  System  Software  Command,  Fort  Lee,  Va 

Department  of  the  Navy: 

-  Naval  Undersea  Warfare  Center,  New  London,  Ct 

-  Navy  Fleet  Materiel  Support  Office  (FMSO),  Mechanicsburg,  Pa 

-  Navy  Management  Systems  Support  Office,  Chesapeake,  Va 

Department  of  Defense,  National  Security  Agency,  Office  of  Information  Technology 
Management,  Fort  Meade,  Md 


The  Institute  for  Defense  Analyses,  Alexandria,  Va 

Marine  Corps  Logistics  Base,  Information  Resources  Managements  Directorate, 
Albany,  Ga 

The  MITRE  Corporation,  Center  for  Information  Systems,  McLean,  Va 
Software  Engineering  Institute,  Carnegie  Mellon  University,  Pittsburgh,  Pa 


Accesion  For 

NTIS  CRA&I 

DTIC  TAB 

Unannounced 

Justification 

□ 

FOREWORD 


1.  The  Software  Systems  Reengineering  Process  Model  is  intended  for  use  by  all 
Departments  and  Agencies  of  the  Department  of  Defense.  This  Model  provides  guidance  for 
applying  software  reengineering  technology  for  the  development  and  modernization  of 
automated  information  support  within  the  Department  of  Defense. 

2.  Beneficial  comments  (recommendations,  additions,  deletions)  and  any  pertinent  data  which 
may  be  of  use  in  improving  this  document  should  be  addressed  to: 

Defense  Information  Systems  Agency 
Joint  Interoperability  and  Engineering  Organization 
Center  for  Software 

Software  Systems  Engineering  Department 
701  South  Courthouse  Road,  Arlington,  VA  22204-2199 

3.  The  DoD  Components  may  obtain  copies  of  this  document  through  their  own  publication 
channels.  Defense  Contractors,  and  other  Federal  Agencies  may  obtain  copies  from: 

Defense  Technical  Information  Center  (DTIC) 

Building  5  Cameron  Station 
Alexandria,  VA  22304-4301 

Commercial  Telephone:  1-800-225-DTIC  (1-800-225-3842) 

4.  This  Model  is  not  intended  to  specify  or  discourage  the  use  of  any  particular  software 
development  method.  The  implementer  of  this  model  is  responsible  for  selecting  software 
development  methods  that  best  support  the  achievement  of  the  software  reengineering  project 
goals.  The  Model  represents  a  view  of  software  reengineering  that  is  independent  of  specific 
tools,  methodologies,  and  domains. 

5.  This  Model  must  be  appropriately  tailored  by  the  project  manager  to  ensure  that  the 
necessary  and  cost-effective  activities  of  software  reengineering  are  implemented.  Assistance 
in  tailoring  this  document  is  available  from  the  Software  Reengineering  Program  located  at 
the  address  in  paragraph  2  of  this  Foreword. 

6.  The  Center  for  Software  is  chartered  to  support  the  Office  of  the  Assistant  Secretary  of 
Defense  (OASD)  for  Command,  Control,  Communications,  and  Intelligence  (C^I)  by 
providing  information  management  technical  services  to  the  DoD  community.  The  services 
are  an  integral  part  of  the  Corporate  Information  Management  program,  a  DoD-wide  effort  to 
streamline  business  operations  and  processes  which  will  help  improve  the  design  of 
cost-effective,  standard  information  systems. 
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1.  SCOPE 


1 . 1  Purpose.  The  Center  for  Software's  Software  Systems  Reengineering  Process  Model 
provides  guidance  for  applying  software  reengineering  technology  for  the  development  and 
migration  of  automated  information  systems  (AISs)  within  the  Department  of  Defense  (DoD). 
The  Center  for  Software  is  chartered  to  support  the  Office  of  the  Assistant  Secretary  of 
Defense  (C^I)  by  providing  information  management  technical  services  to  the  DoD 
community.  The  services  are  an  integral  part  of  the  Corporate  Information  Management 
program,  a  DoD-wide  effort  to  streamline  business  operations  and  processes  which  will  help 
improve  the  design  of  cost-effective,  standard  information  systems.  This  document  introduces 
the  reader  to  the  software  reengineering  process  composed  of  activities  for  creating  AISs  to 
support  current  business  needs. 

The  Software  Systems  Reengineering  Process  Model  captures  the  essence  of  software 
reengineering  as  it  applies  in  the  DoD  Information  Management  (IM)  community.  Software 
reengineering  is  composed  of  activities  supporting  the  development  and  maintenance  of 
automated  information  systems  based  on  the  examination  and  utilization  of  existing  software 
system  resources.  Reengineering  emerges  as  a  strategy  for  bringing  the  cost  of  developing 
and  maintaining  software  under  control.  The  need  for  a  comprehensive  plan  to  apply 
software  reengineering  technology  is  the  driving  force  behind  the  Center's  Software 
Reengineering  Program.  The  Software  Systems  Reengineering  Process  Model  will  assist 
managers  facing  this  situation. 


1.2  Application.  This  Model  is  intended  for  use  by  all  Departments  and  Agencies  of  the 
Department  of  Defense.  This  Model  provides  guidance  for  applying  software  reengineering 
technology  for  the  development  and  modernization  of  automated  information  systems  within 
the  Department  of  Defense.  Any  part  of  the  Model  may  be  tailored  and  implemented  to  meet 
organizational  goals  through  software  reengineering  technology. 


1.2.1  Tailoring.  This  Model  is  intended  to  be  tailored  by  the  project  manager  to  ensure  that 
the  necessary  and  cost-effective  activities  of  software  reengineering  are  implemented.  A 
subset  of  this  Model  may  be  selected  to  meet  the  reengineering  project  objectives.  The 
activities  in  this  Model  should  be  refined  to  the  level  where  activities  can  be  costed  and 
products  listed  by  name.  These  lowest  level  activities  have  one  output  product  and  one 
function  to  perform.  Assistance  in  tailoring  the  Model  is  available  from  the  Software 
Reengineering  Program  located  at  the  address  in  the  Foreword  of  this  document. 


1.3  Benefits.  Two  broad  concepts  guide  software  reengineering  in  the  DoD.  The  first 
concept  is  the  prevention  of  duplication  by  joint  use  of  personnel,  information  systems, 
facilities,  and  services  across  DoD.  The  second  concept  is  conformance  to  new  regulations, 
policy,  standards,  and  guidelines  for  software  acquisition  and  support.  The  Model  integrates 
the  software  reengineering  process  with  the  mechanisms  provided  by  these  available 
technologies  that  provide  the  software  engineering  environment  and  the  regulations,  policy, 
standards  and  guidelines  governing  software  development  and  maintenance  under  DoD  IM. 
Software  reengineering  is  also  explored  as  a  means  for  improving  the  quality  and  reducing  the 
cost  associated  with  the  development  and  maintenance  of  computer  software  systems. 

The  Technical  Review  held  in  June  1994  brought  together  representatives  from  organizations 
in  the  Department  of  Defense  who  are  tasked  with  performing  software  reengineering  or 
developing  guidelines  for  how  software  reengineering  should  be  applied  in  the  DoD.  These 
representatives  reached  consensus  on  a  software  reengineering  process  which  is  described  in 
the  Software  Systems  Reengineering  Process  Model,  Version  2.0  defined  in  this  document. 

Only  recently  have  there  been  reengineering  efforts  of  the  magnitude  to  produce  data  that  is 
useful  in  predicting  the  success  of  reengineering.  Some  of  these  efforts  have  defined  process 
models  and  were  examined  in  preparation  for  defining  the  Software  Systems  Reengineering 
Process  Model  [ByGu92,  ChCr90,  HoMi91,  M1TR92,  RuGu91]. 


1-2 


1.4  Context.  The  software  reengineering  process  for  DoD  AIS  is  defined  by  the  process 
model  described  in  this  document.  This  process  is  composed  of  activities  that  examine 
existing  software  systems  and  utilize  resources  extracted  from  these  systems  to  develop  new 
AISs  and  modernize  existing  AISs.  Figure  1  presents  a  frame  of  reference  for  this 
reengineering  process.  It  relates  software  reengineering  to  other  processes  within  the 
information  management  domain.  For  clarity,  Figure  1  shows  only  major  inputs  and  outputs 
and  does  not  identify  controls  or  mechanisms  for  information  management. 

Functional  Process  Improvement  (FPI)  drives  the  overall  software  reengineering  process 
[DoD92a].  FPI  guides  managers  to  identify  the  current  business  needs  and  implement 
business  process  improvements.  Reverse  engineering  is  employed  to  obtain  an  accurate 
description  of  the  current  AIS  environment.  The  functional  requirements  are  forward 
engineered  into  new  AISs  according  to  appropriate  standards.  A  process  for  performing 
reengineering  is  defined  by  the  Software  Systems  Reengineering  Process  Model  described  in 
this  paper. 

FPI  programs  enable  functional  managers  to  identify  current  problems,  including  poor 
business  practices,  establish  costs  for  business  activities,  propose  changes  and  implement 
business  improvements.  Technical  Improvement  opportunities  may  result  from  technology 
changes  identified  in  the  Technical  and  Economic  Analysis  Process  or  operational  experience 
with  existing  AISs.  In  addition,  reverse  engineered  products,  including  business  rules,  process 
models,  and  data  models,  may  be  required  if  information  on  the  existing  business  processes 
are  not  well  documented. 

Cost  and  quality  improvement  are  often  direct  drivers  of  reengineering  as  they  are  primary 
forces  behind  FPI.  The  ability  to  support  information  management  systems  in  a  cost-effective 
manner  and  improve  the  quality  of  information  management  products  are  organizational  goals 
that  can  be  achieved  through  software  reengineering.  These  two  drivers  may  not  be  linked  to 
FPI. 
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Technical  and  Economic  Analysis  is  performed  to  determine  the  technical  and  economic 
feasibility  of  using  AISs  to  support  the  business  processes.  Characteristics  of  the  current  AIS 
environment  are  compared  with  the  functional  requirements  and  available  commercial 
technologies.  Reverse  engineered  products  may  be  required  if  an  accurate  description  of  the 
current  AIS  baseline  does  not  exist.  The  technical  analysis  process  produces  recommendations 
on  the  use  of  technology  and  eventually  an  implementation  plan. 

The  functional  and  technical  requirements  are  then  used  to  develop  a  new  system  or 
reengineer  an  existing  system.  New  systems  follow  processes  specified  in  existing  military  or 
commercial  standards.  The  software  reengineering  process  is  defined  in  the  Software  Systems 
Reengineering  Process  Model.  AISs  are  developed,  reengineered,  implemented,  operated  and 
maintained  under  configuration  control. 


1.5  Process  Model  Overview.  The  activities  described  in  the  Software  Systems 
Reengineering  Process  Model  capture  the  essence  of  the  software  reengineering  process  as  it 
applies  in  the  DoD  IM  community.  This  process  is  composed  of  three  high-level  activities, 
including  Define  Project  (initial  project  planning).  Reverse  Engineer,  and  Forward  Engineer. 
Figure  2  depicts  a  node  tree  which  represents  each  activity  of  the  Model  as  a  node  and  shows 
how  each  activity  is  composed  of  subordinate  activities. 

This  Model  serves  as  a  guide  to  performing  software  reengineering  to  develop  and  support 
automated  information  systems  which  implement  functional  and  technical  requirements,  while 
in  the  context  of  the  DoD  Enterprise  Model. 


AO 

Reengineer 
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A1 
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A11 
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Objectives 

A12 

Identify 

Baseline 


A13 
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Reengineering 
Project  Plan 


A1 1 1  Develop  Objectives  and  Success  Factors 
A112  Identify  Metrics 
A113  Identify  Risks 

A121  Identify  Existing  Application  Software 

A122  Identify  Existing  Data 

A123  Identify  Existing  Technical  Infrastructure 

A131  Develop  Reengineering  Strategy 
A132  Identify  Methodologies  and  Tools 
A133  Allocate  Resources 
A134  Produce  Reengineering  Project  Pian 


A2 

Reverse 

Engineer 


A3 

Forward 

Engineer 


A21  Analyze  Documentation 
A22  Analyze  Application  Software 
A23  Analyze  Data 
A24  Analyze  Technical  Infrastructure 
A25  Reconcile  Extracted  Products 

A31  Analyze 

A32  Design 

A33  Build 

A34  Integrate 

A35  Test  and  Evaluate 


Figure  2.  Software  Systems  Reengineering  Process  Model  Node  Tree 


1.6  IDEF  Function  Modeling  Overview.  The  Software  Systems  Reengineering  Process 
Model  is  represented  using  the  Integrated  Computer-Aided  Manufacturing  (ICAM)  DEFinition 
language  (IDEF)  for  function  modeling  (IDEFO).  IDEF  was  developed  in  the  United  States 
Air  Force  ICAM  program.  Today,  the  IDEF  method  is  required  for  all  function  modeling 
[DoD92a].  IDEFO  is  used  to  produce  a  functional  model  that  is  a  structured  representation  of 
activities  or  functions  and  the  relationship  between  those  activities. 
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IDEFO  models  are  composed  of  activities  ("what  is  done")  and  interfaces,  including  inputs, 
controls,  outputs,  and  mechanisms  (Figure  3).  Activities  are  represented  as  boxes  and  the 
interfaces  are  depicted  as  arrows,  entering  and  leaving  the  boxes.  Inputs  enter  from  the  left 
and  outputs  leave  from  the  right  of  the  box;  the  activity  transforms  inputs  to  outputs. 

Controls  enter  at  the  top  of  the  box;  they  provide  direction  and  constraint.  Mechanisms, 
representing  the  means  used  to  perform  the  activity,  enter  from  the  bottom.  Mechanisms  may 
include,  people,  databases,  or  equipment  that  support  or  perform  the  activity. 


CONTROL:  Interfaces  that 
guide  or  regulate  the  activity 


INPUTS:  Interfaces  that 
are  changed  as  a  result 
of  the  activity 


ACTIVITY 

OUTPUTS:  Results 
of  the  activity 


MECHANISMS:  Systems,  organizations, 
people,  databases,  or  equipment  that 
support  or  perform  the  activity 


Figure  3.  IDEF  Activity  Model 

The  organization  of  the  IDEFO  activities  and  their  relationships  with  each  other  are  not  related 
to,  concerned  with,  or  limited  by  time.  These  activities  are  refined  into  greater  detail  in 
subsequent  diagrams. 
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2.  REFERENCED  DOCUMENTS 


2.1  Government  documents. 


2.1.1  Specifications,  standards,  and  handbooks.  The  following  specifications,  standards,  and 
handbooks  form  a  part  of  this  document  to  the  extent  specified  herein.  Unless  otherwise 
specified,  the  issues  of  these  documents  are  those  most  current. 


DoD-STD-2167A 
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and  Lessons  Learned,"  NIST  Special  Publication  500-193,  National 
Institute  of  Standards  and  Technology,  Sep  1991. 
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2.2  Non-Govemment  documents. 

2.2.1  Non-Govemment  standards. 

FIPS  146-2  Government  Open-Systems  Interconnection  Protocol  (GOSIP) 

FIPS  151-1  Portable  Operating  System  Interface  Exchange  (POSIX) 

FIPS  183  IDEF 

IEEE  STD  610.12  Institute  of  Electrical  and  Electronics  Engineers,  Inc.,  IEEE 

Standard  Glossary  of  Software  Engineering  Terminology,  IEEE 
Std  610.12-1990,  Dec  10,  1990. 

2.2.2  OtherNon-Govemment  documents,  drawings,  and  nublications. 


[Basi93]  V.R.  Basili,  Software  Modeling  and  Measurement:  The 

Goal/Ouestion/Metric  Paradigm.  Institute  for  Advanced  Computer 
Studies,  Department  of  Computer  Science,  University  of  Maryland, 
developed  under  NASA/GSFC  contract  NSG-5123  and  AFOSR  contract 
90-0031,  1993. 


[ByGu92]  E.  J.  Byrne  and  D.  A.  Gustafson,  "A  Software  Reengineering  Process 
Model,"  Conference  on  Computer  Software  and  Applications 
rCOMPSACh  Sep  1992,  Chicago,  IL. 

[CMU92]  Software  Measurement  for  DoD  Systems:  Recommendations  for  Initial 
Core  Measures.  TR  CMU/SEI-92-TR-19,  Sep  1992. 


[ChCr90]  E.  J.  Chikofsky  and  J.  H.  Cross,  "Reverse  Engineering  and  Design 
Recovery:  A  Taxonomy,"  IEEE  Software,  pp.  13-17,  Jan  1990. 
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3.  SOFTWARE  SYSTEMS  REENGINEERING  PROCESS  MODEL 


The  Model  is  composed  of  diagrams  and  a  glossary  of  the  activities  and  their  inputs,  controls, 
outputs,  and  mechanisms.  This  Section  3  presents  each  activity  in  a  diagram.  Each  diagram 
shows  all  the  inputs,  controls,  outputs,  and  mechanisms  for  each  activity  of  the  Model.  An 
alphabetic  listing  of  the  definitions  for  all  the  activities  and  their  inputs,  outputs,  controls,  and 
mechanisms  are  contained  in  Section  4.  GLOSSARY  OF  THE  MODEL. 
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4.  GLOSSARY  OF  THE  MODEL 


The  following  is  an  alphabetic  listing  of  the  definitions  for  all  the  activities  and  their  inputs, 
outputs,  controls,  and  mechanisms  in  the  Model.  Definitions  for  all  activities  are  presented 
first  in  the  "Activity  Pool."  The  "Concept  Pool"  follows  containing  the  definitions  for  all 
inputs,  controls,  outputs,  and  mechanisms.  Each  definition  contains  a  "Usage"  section.  The 
Usage  for  activities  identifies  the  diagram  where  the  activity  appears  and  its  node  number. 
For  example  the  activity  called  "Reengineer  System"  appears  in  Diagram  Cl  as  Activity  AO. 
The  Usage  for  each  concept  states  whether  the  concept  is  an  input,  control,  output,  or 
mechanism.  For  each  usage  of  each  concept,  the  node  number  and  name  of  the  related 
activity  and  the  diagram  is  identified.  For  example,  "Automated  Information  System"  is  an 
Input  on  Activity  AO  (Reengineer  System)  in  Diagram  Cl. 
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Project:  SAV  Systems  Reengineering;  Date:  12/19/94 


Activity  Pool 


Allocate  Resources 


Define  the  resources  for  performing  the  reengineering  project,  including  allocation  of  funds,  personnel,  tools,  and 
computer  resources.  Available  funding  and  computer  resource  support  for  methodologies  and  tools  are 
determined.  Necessary  training  for  personnel  on  computer  resources,  methodologies,  and  tools  is  also  determined. 


Usage 

Appears  in  Diagram  C 15  as  A 133 


Analyze 


The  Business  Requirements  and  the  Reverse  Engineered  Products  are  analyzed  during  this  activity  to  generate  the 
Analysis  Deliverables.  Reengineering  Project  Plan  and  Regulations,  Policy,  Standards,  and  Guidelines  analysis 
define  this  activity,  including  the  Analysis  Deliverables.  The  Analysis  Deliverables  include  requirements  for 
Testing  and  a  formal  specification  of  the  analyzed  Business  Requirements  which  are  not  addressed  in  the  Reverse 
Engineered  Products  and  must  be  forward  engineered. 


Usage 

Appears  in  Diagram  Cl 3  as  A3 1 


Analyze  Application  Software 

This  activity  analyzes  the  existing  application  software  to  extract  software  products,  including  but  not  limited  to 
process  models  and  the  information  needed  to  define  the  business  rules,  design  model,  system  specification, 
functional  requirements,  data  models,  and  design  decisions.  The  activity  also  includes  collecting  metric  data. 


Usage 

Appears  in  Diagram  Cl 2  as  A22 
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Project:  SAV  Systems  Reengineering;  Date:  12/19/94 


Analyze  Data 


This  activity  analyzes  the  existing  data  to  extract  data  products,  including  but  not  limited  to  data  models  and  the 
information  needed  to  define  the  business  rules,  design  model,  system  specification,  functional  requirements, 
process  models  and  design  decisions.  The  activity  also  includes  collecting  metric  data. 

Usage 

Appears  in  Diagram  Cl 2  as  A23 


Analyze  Documentation 


This  activity  analyzes  the  existing  documentation  to  extract  documentation  products,  including  but  not  limited  to 
information  needed  to  define  the  business  rules,  design  model,  system  specification,  technical  infrastructure 
capabilities,  data  models,  process  models,  and  design  decisions.  The  activity  also  includes  collecting  metric  data. 


Usage 

Appears  in  Diagram  C12  as  A21 

Analyze  Technical  Infrastructure 


This  activity  analyzes  the  existing  technical  infrastructure  to  extract  technical  infrastructure  products  including, 
but  not  limited  to  the  technical  infrastructure  and  the  information  needed  to  collect  metric  data  and  define  design 
decisions. 


Usage 

Appears  in  Diagram  C12  as  A24 


Build 


The  Design  Components  are  used  to  generate  the  Build  Components.  Reusable  Assets  are  employed  as  possible. 
The  Test  Results  verify  whether  the  Build  Components  conform  to  specification.  The  Reengineering  Project  Plan 
and  Regulations,  Policy,  Standards,  and  Guidelines  concerning  build  procedures  define  this  activity,  the  structure 
for  the  Build  Components  and  the  expected  Build  Results. 
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Project:  SAV  Systems  Reengineering;  Date:  12/19/94 


Usage 

Appears  in  Diagram  Cl 3  as  A33 


Define  Objectives 


The  objectives  of  the  reengineering  effort  are  identified  by  the  organizational  goals  of  the  reengineering  effort, 
including  objectives  for  using  the  system,  supporting  the  system,  and  the  objectives  of  utilizing  reengineering 
technology.  The  Project  Team  identifies  the  objectives  and  interviews  those  individuals  whose  objectives  are  to 
be  included  as  part  of  the  reengineering  effort.  This  activity  defines  the  target  environment  (software  and 
hardware)  and  the  intended  maintenance  and  operational  plans. 

Development  of  concrete  measurable  objectives  is  an  essential  step  in  establishing  the  foundation  for  developing  a 
project  strategy  contained  to  guide  the  efforts  of  the  reengineering  effort.  The  expression  of  these  goals  should 
show  how  the  business  needs  of  the  organization  and  new  system  requirements  will  be  met,  and  how  Regulations, 
Policy,  Standards,  and  Guidelines,  and  the  schedule  will  control  the  reengineering  effort,  and  what  is  expected  of 
the  methodologies  and  tools  that  will  be  applied  during  the  reengineering  effort. 

Define  Objectives  is  composed  of  the  activities:  Develop  Objectives  and  Success  Factors,  Identify  Metrics,  and 
Identify  Risks. 


Usage 

Appears  in  Diagram  Cl  1  as  A1 1 


Define  Project 


The  Project  Team  defines  the  Reengineering  Project  Plan  during  the  Define  Project  activity  by  examining  the 
organization's  Business  Requirements,  the  existing  Automated  Information  System  and  Available  Reengineering 
Technology.  Any  Feasibility  Analysis  Results  that  are  available  should  be  examined  for  information  useful  in 
defining  this  plan. 

The  business  requirements  which  can  be  reverse  engineered  and  those  which  must  be  implemented  during  the 
Forward  Engineer  activity  are  identified  and  reconciled  during  the  Define  Project  activity.  The  identity  of  those 
requirements  addressed  in  the  existing  AIS  may  not  be  available  until  the  AIS  is  reverse  engineered.  Reverse 
Engineered  Products  are  used  to  update  and  revise  the  Reengineering  Project  Plan  accordingly.  Analysis 
Deliverables  supply  information  about  the  Business  Requirements  to  be  implemented  during  Forward  Engineering 
and  are  used  to  update  and  revise  the  Reengineering  Project  Plan. 

The  Define  Project  activity  also  identifies  critical  success  factors  which  will  indicate  whether  the  reengineering 
effort  was  successful.  The  Project  Team  should  employ  Methodologies  and  Tools  for  planning  the  project, 
including  project  and  configuration  management  tools.  Repositories  are  used  to  retrieve  information  about 
Available  Reengineering  Technology  and  the  Automated  Information  System.  Define  Project  is  composed  of  the 
activities:  Define  Objectives,  Identify  Baseline,  and  Define  Reengineering  Project  Plan. 
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Project;  SAV  Systems  Reengineering;  Date:  12/19/94 


Usage 

Appears  in  Diagram  CIO  as  A 1 


Define  Reengineering  Project  Plan 


Define  a  structured  plan  for  accomplishing  the  reengineering.  This  plan  will  dictate  how  Regulations,  Policy, 
Standards,  and  Guidelines  will  be  followed.  This  activity  is  composed  of  the  activities  called  Develop 
Reengineering  Strategy,  Identify  Tools  and  Methodologies,  Allocate  Resources,  and  Produce  Reengineering 
Project  Plan  for  implementing  the  reengineering.  The  Reengineering  Project  Plan  contains  the  information  in  the 
products  of  these  activities. 

Usage 

Appears  in  Diagram  C 1 1  as  A 1 3 


Design 


The  Analysis  Deliverables  and  the  Reverse  Engineered  Products  concerning  Design  are  u.sed  to  generate  the 
Design  Components  during  this  activity.  The  Reengineering  Project  Plan  and  Regulations,  Policy,  Standards,  and 
Guidelines  concerning  Design  define  this  activity,  the  structure  for  the  Design  Components  and  the  expected 
Design  Results. 


Usage 

Appears  in  Diagram  C13  as  A32 


Develop  Objectives  &  Success  Factors 

This  activity  identifies  the  Objectives  of  the  reengineering  project  links  these  Objectives  to  Critical  Success 
Factors  to  prove  the  success  of  the  reengineering  project.  These  Objectives  must  also  be  mapped  to  Metrics  and 
their  associated  Risks. 

Usage 

Appears  in  Diagram  C17  as  A1 1 1 

Develop  or  Reengineer  Systems 

Functional  (Business)  Requirements  and  Technical  Requirements  are  used  to  either  develop  new  systems  or  utilize 
existing  AISs  to  reengineer  systems.  These  activities  follow  the  processes  specified  in  eixsting  military  or 
commercial  standards.  AISs  are  developed  and  reengineered  under  configuration  management. 
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Project:  SAV  Systems  Reengineering;  Date:  12/19/94 


Usage 

Appears  in  Diagram  Cl 8  as  A3 


Develop  Reengineering  Strategy 


The  Project  Strategy  identifies  reengineering  alternatives  which  include  scenarios,  possible  incorporation  of  new 
technology  and  approaches,  and  the  use  of  methodologies  and  tools.  Possible  scenarios  include,  but  are  not 
limited  to  restructuring,  redocumentation,  and  data  rationalization.  The  alternatives  are  evaluated  with  respect  to 
objectives  and  risks.  A  strategy  for  reengineering  is  selected  from  the  possible  alternatives. 

The  reengineering  strategy  should  address  the  development  of  a  reengineering  testing  strategy  and  an  acceptance 
testing  strategy.  Certification  procedures  are  part  of  the  acceptance  testing  strategy.  A  portfolio  analysis  may  be 
performed.  The  Project  Strategy  drives  the  selection  of  methodologies  and  tools,  requiring  these  to  adequately 
support  the  Project  Strategy  through  Revisions  to  Proposed  Methodologies  and  Tools. 


Usage 

Appears  in  Diagram  C 15  as  A131 


Figure  1.  Context  for  Information  Management 

Usage 

Appears  in  Model  C16  (Figure  1.  Context  for  Information  Management)  as  AO 


Forward  Engineer 


Within  the  context  of  reengineering,  forward  engineering  is  the  software  engineering  activities  that  consume  the 
products  of  reverse  engineering  and  reuse  activities,  and  new  system  requirements  to  produce  a  target  system 
[CIM93a].  The  Project  Team  performs  traditional  life-cycle  development  that  is  moving  from  high-level 
abstractions  and  logical  implementation-independent  design  to  the  physical  implementation  of  the  system.  DoD 
Enterprise  Model  and  Other  Models  are  employed.  Regulations,  Policy,  Standards,  and  Guidelines  concerning 
application  software  are  complied  and  the  schedule  adhered. 

All  of  the  components  should  be  implemented  during  forward  engineering  as  Candidate  Reusable  Assets. 
Appropriate  standards,  including  DOD-STD-2167A,  the  draft  DOD-STD-498  and  subsequent  standards  which 
should  be  followed  when  producing  the  applicable  documents. 

Forward  Engineering  is  composed  of  the  activities  called  Analyze,  Design,  Build,  Integrate,  and  Test  &  Evaluate. 
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Project;  SA\'  Systems  Reengineering;  Date;  12/19/94 


Usage 

Appears  in  Diagram  CIO  as  A3 


Identify  Baseline 

The  Project  Team  will  identify  the  configuration  items  which  comprise  the  current  automated  information  system. 
This  activity  does  not  analyze  these  configuration  items,  but  simply  identifies  the  system  upon  which  the 
reengineering  activities  will  be  performed.  These  items  include,  but  are  not  limited  to  the  technical  infrastructure, 
data,  application  software,  and  all  associated  documentation.  Methodologies  and  Tools  are  available  which  assist 
in  identifying  these  configuration  items. 

Objectives  may  control  the  activity  of  Identify  Baseline  by  impacting  the  identification  of  the  Baselined  AIS 
Components.  Examples  of  such  Objectives  include  the  objective  to  reengineer  a  previous  identification  version  or 
the  objective  to  reconcile  several  versions  of  the  same  system. 


Usage 

Appears  in  Diagram  Cl  1  as  A12 


Identify  Existing  Application  Software 

Identify  the  application  software  and  associated  documentation  for  this  information  system.  This  software  does 
not  include  Commercial-Off-the-Shelf  (COTS)  software. 


Usage 

Appears  in  Diagram  C14  as  A121 

Identify  Existing  Data 

Identify  the  existing  data  configuration  items  and  associated  documentation  for  this  information  system. 


Usage 

Appears  in  Diagram  C 14  as  A 1 22 
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Project:  SAV  Systems  Reengineering;  Date:  12/19/94 


Identify  Existing  Technical  Infrastructure 

Identify  the  technical  infrastructure  and  associated  documentation  for  this  information  system. 


Usage 

Appears  in  Diagram  C 14  as  A 123 


Identify  Methodologies  and  Tools 


Proposed  Methodologies  and  Tools  are  identified  by  an  analysis  of  Available  Reengineering  Technology.  The 
Proposed  Methodologies  and  Tools  must  integrate  into  the  sponsoring  organizations  current  software  engineering 
environment  and  support  the  automation  of  activities  defined  by  the  Project  Strategy.  The  Define  Project  Strategy 
may  require  Revisions  in  Selected  Methodologies  and  Tools  to  adequately  support  the  Project  Strategy.  The 
Allocate  Resources  activity  may  require  Revisions  in  Selected  Methodologies  and  Tools  to  insure  these  adhere  to 
Project  Resources.  The  Generate  Reengineering  Project  Plan  may  also  require  Revisions  in  Selected 
Methodologies  and  Tools  to  insure  overall  compliance  with  the  controls  and  Business  Requirements. 


Usage 

Appears  in  Diagram  C 15  as  A 132 

Identify  Metrics 

This  activity  uses  the  Objectives  of  the  reengineering  project  to  identify  a  set  of  metrics  which  can  be  used  to 
determine  if  the  Objectives  are  being  met  throughout  the  project's  duration. 

Usage 

Appears  in  Diagram  C17  as  A1 12 


Identify  Risks 

This  activity  identifies  the  potential  risks  associated  with  the  Objectives.  By  identifying  these  risks,  steps  can  be 
taken  to  help  mitigate  the  impact  should  they  occur.  The  potential  impact  on  the  reengineering  project  if  these 
risks  occur  should  be  identified  and  a  risk  management  plan  outlined. 

Usage 

Appears  in  Diagram  C17  as  A1 13 
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Project;  SAV  Systems  Reengineering;  Date:  12/19/94 


Implement,  Operate  &  Maintain 

The  system  is  implemented,  operated,  and  maintained  under  configuration  management.  During  this  time 
operational  experience  is  cummulated  and  used  to  assess  and  improve  the  direction  of  guidance  for  DoD. 

Usage 

Appears  in  Diagram  C18  as  A5 


Integrate 


Any  number  of  Build  Components  are  integrated  to  form  Integrated  Components.  This  activity  insures  the 
interfaces  between  Build  Components  are  complete.  Regulations,  Policy,  Standards,  and  Guidelines  concerning 
integration  procedures  and  the  Reengineering  Project  Plan  define  this  activity,  including  the  structure  for  the 
Integrated  Components  and  the  expected  Integration  Results. 


Usage 

Appears  in  Diagram  C13  as  A34 


Perform  Functional  Process  Improvement 

(FPI)  guides  managers  to  identify  the  current  business  needs  and  implement  business  process  improvements. 
Reverse  Engineered  Products  are  used  to  obtain  an  accurate  description  of  the  current  AIS  environment.  The 
functional  requirements  are  forward  engineered  into  new  or  reengineered  systems  according  to  appropriate 
standards. 

FPI  enables  managers  to  identify  current  problems,  including  poor  business  practices,  e.stablish  costs  for  activities, 
propose  changes  and  implement  business  improvements.  Technical  Improvement  Opportunities  result  from 
technology  changes  identified  in  the  Perform  Technical  &  Economic  Analysis  activity. 

Usage 

Appears  in  Diagram  Cl 8  as  A 1 


Perform  Information  Management 

Usage 

None 
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Project:  SAV  Systems  Reengineering;  Date:  12/19/94 


Perform  Technical  &  Economic  Analysis 

Technical  &  Economic  Analysis  is  performed  to  determine  the  technical  and  economic  feasibility  of  using  AISs  to 
support  the  business  processes.  Reverse  Engineered  Products  providing  a  description  of  the  current  AIS 
environment  and  Operational  Experience  are  compared  to  the  Functional  (Business)  Requirements  and  available 
technology  to  produce  recommendations  on  the  use  of  technology  in  the  Technical  Improvement  Opportunities. 

Usage 

Appears  in  Diagram  C18  as  A2 


Produce  Reengineering  Project  Plan 


The  Project  Plan  is  developed  by  reconciling  the  Project  Resources,  Project  Strategy,  and  Project  Methodologies 
and  Tools.  The  Plan  must  adhere  to  applicable  Regulations,  Policy,  Standards,  and  Guidelines.  The  Plan  is 
validated  against  the  Objectives  for  the  Project.  Recommended  changes  to  the  Other  Models,  Technical 
Architectures,  and  Objectives  may  be  generated.  A  procedure  for  tracing  the  products  of  the  reengineering  effort 
to  the  Objectives  and  Business  Requirements  are  outlined. 


Usage 

Appears  in  Diagram  C 15  as  A 134 


Reconcile  Extracted  Products 


This  activity  integrates  the  information  contained  in  the  Extracted  Documentation  Products,  Extracted  Software 
Products,  Extracted  Data  Products,  and  the  Extracted  Technical  Infrastructure  Products  to  form  the  Reverse 
Engineered  Products.  The  Reverse  Engineered  Products  may  include,  but  are  not  limited  to  the  business  rules, 
design  models,  system  specifications,  functional  requirements,  metric  data,  data  models,  process  models,  and 
design  decisions. 


Usage 

Appears  in  Diagram  C12  as  A25 


Redocumentation 

Redocumentation  produces  supplementary  information  that  provides  understanding  of  the  existing  system  and  its 
components  [CIM93a].  This  activity  does  not  alter  the  existing  system  implementation.  Redocumentation  is 
often  performed  during  Reverse  Engineer  activity  to  produce  interim  documentation  that  is  used  to  generate  or  is 
converted  to  the  Reverse  Engineered  Products. 
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Project:  SAV  Systems  Reengineering;  Date:  12/19/94 


Usage 

None 


Reengineer  System 


Reengineering  describes  the  activities  supporting  the  development  and  migration  of  automated  information 
systems  based  on  the  examination  and  alteration  of  existing  software  systems. 

The  Business  Requirements  are  those  requirements  which  are  proposed  for  implementation  in  the  Reengineered 
System.  Some  of  these  requirements  may  be  implemented  in  the  existing  automated  information  system,  while 
others  may  have  to  be  implemented  during  the  forward  engineering  process.  Feasibility  Analysis  Results  may  be 
available  to  provide  information  to  support  the  comprehensive  reengineering  project.  Reusable  Assets  should  be 
explored  for  use  throughout  the  reengineering  effort. 

The  DoD  Enterprise  Model  provides  the  high-level  vision  for  the  Reengineered  System,  while  Other  Models 
govern  the  domain  in  which  this  system  will  operate.  Regulations,  Policy,  Standards,  and  Guidelines  govern  the 
activities  and  products  to  be  produced  during  the  reengineering.  Resource  Limitations  provide  the  scope  in  which 
the  reengineering  effort  is  supported.  Technical  Architectures  provide  an  infrastructure  in  which  the 
Reengineered  System  must  execute.  Available  Reengineering  Technology  is  examined  for  its  applicability  in  this 
specific  project. 

The  reengineering  effort  often  produces  a  complete  Reengineered  System,  as  well  as  Candidate  Reuse  As.sets 
which  may  support  other  development  and  migration  efforts.  As  experience  in  reengineering  increases. 
Recommended  Changes  to  Controls  governing  these  activities  will  help  improve  the  proce.sses. 

Software  Engineering  Environment  which  supports  software  reengineering  is  composed  of  a  Project  Team, 
Methodologies,  Tools,  Repositories,  and  a  Computing/Communications  Infrastructure. 

The  selection  of  the  members  of  the  Project  Team  is  key  to  a  successful  project.  Matching  skills  with  the 
activities  described  in  this  model  insures  productivity  and  minimizes  risk.  The  activities  described  in  this  model 
support  an  overall  migration  plan.  The  selection  of  automated  information  systems  for  reengineering  supports 
successful  process  improvement.  The  selection  of  team  members,  migration  plan  development,  and  candidate 
selection  are  not  addressed  in  this  model,  but  support  the  overall  reengineering  process. 

The  Reengineer  System  activity  is  composed  of  three  activities;  Define  Project,  Reverse  Engineer,  and  Forward 
Engineer. 


Usage 

Appears  in  Model  C 1  as  AO 


Restructuring 

The  transformation  from  one  representation  form  to  another  while  preserving  the  external  behavior,  both 
functionally  and  semantically  [ChCr90].  Restructuring  is  performed  to  improve  the  existing  structure  without 
altering  the  functionality.  Restucturing  is  often  used  to  improve  maintainability. 
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Usage 

None 


Reverse  Engineer 


The  Project  Team  examines  the  Baselined  AIS  Components  by  analyzing  the  documentation,  application  software, 
data  structures  and  the  technical  infrastructure  within  which  the  information  system  operates.  This  analysis  is 
performed  to  identify  the  system  components  and  their  interrelationships,  and  to  create  representations  of  the 
system  in  another  form  or  at  a  higher  abstraction  level  to  provide  a  better  understanding  of  the  system  as  defined 
by  reverse  engineering  [ChCr90,  CIM93a]. 

Reusable  Assets  should  be  used  to  compose  these  representations.  Reverse  Engineering  Tools  are  used  in  this 
process  to  produce  manageable  and  usable  Reverse  Engineered  Products  which  become  the  foundation  or 
framework  to  Forward  Engineer.  These  generated  representations  should  be  developed  for  reuse.  These  are 
submitted  to  a  reuse  certification  program  as  Candidate  Reuse  Assets. 

Reverse  Engineer  is  composed  of  the  activities  called:  Analyze  Documentation,  Analyze  Data,  Analyze 
Application  Software,  Analyze  Technical  Infrastructure,  and  Reconcile  Extracted  Products. 


Usage 

Appears  in  Diagram  CIO  as  A2 


Test  and  Evaluate 


The  Integrated  Components  are  tested  using  a  testing  plan  developed  from  the  requirements  defined  in  the 
Analysis  Deliverables.  Individual  Build  Components  are  also  tested  according  to  the  individual  component 
specifications.  The  Reengineering  Project  Plan  and  the  Regulations,  Policy,  Standards,  and  Guidelines  concerning 
test  procedures  define  this  activity  and  the  expected  Test  Results.  The  Test  Results  will  be  evaluated  in 
accordance  with  certification  procedures  identified  in  the  Reengineering  Project  Plan. 


Usage 

Appears  in  Diagram  Cl 3  as  A35 


Transition  to  Operation  &  Maintenance 

The  New  or  Reengineered  System  and  Operational  Experience  are  studied  to  produce  a  Transition  Plan  and 
Training  necessary  to  put  the  system  into  operation  and  subsequent  maintenance. 
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Usage 

Appears  in  Diagram  C18  as  A4 
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Concept  Pool 


AIS 

See  Automated  Information  System. 
Usage 
None 


Analysis  Del.,  Rev  Eng  Products 

See  Analysis  Deliverables  and  Reverse  Engineered  Products. 

Usage 

tunneled  into  Cll 

Input  on  Activity  A13  (  Define  Reengineering  Project  Plan  )  in  Cl  1 

Appears  in  Cll  in  Breakdown  Analysis  Del.,  Rev  ::  Reverse  Engineere,  Analysis  Delivera 

Input  on  Activity  A13  (  Define  Reengineering  Project  Plan  )  in  C15 

Input  on  Activity  A131  (  Develop  Reengineering  Strategy  )  in  C15 


Analysis  Deliverables 


Required  documentation  summarizing  the  results  of  the  analysis  phase.  Refer  to  DOD-STD-2167A,  the  proposed 
DOD-STD-498  and  subsequent  standards  for  guidelines  on  producing  these  documents. 

The  Analysis  Deliverables  include  refined  feasibility  analysis  results,  an  updated  risk  analysis,  and  the 
requirements  for  testing  the  reengineered  system  and  its  components.  These  requirements  are  sent  to  the  Test  & 
Evaluate  activity  in  forward  engineering. 

The  Analysis  Deliverables  also  provide  information  which  impacts  the  Reengineering  Project  Plan.  This 
information  is  provided  to  the  Define  Project  activity  for  updating  the  Plan. 


Usage 

Output  on  Activity  A3  ( Forward  Engineer )  in  CIO 
Input  on  Activity  A1  (  Define  Project )  in  CIO 
Input  on  Activity  A1  (  Define  Project )  in  Cl  1 
tunneled  into  Cll 

Appears  in  Cl  1  in  Breakdown  Analysis  Del.,  Rev  Reverse  Engineere,  Analysis  Delivera 

Output  on  Activity  A31  ( Analyze  )  in  C13 

Output  on  Activity  A3  ( Forward  Engineer  )  in  C13 

Input  on  Activity  A32  ( Design  )  in  C13 

Input  on  Activity  A35  (  Test  and  Evaluate  )  in  Cl 3 
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Automated  Information  System 


(AIS)  Consists  of  any  combination  of  computer  hardware,  computer  software,  telecommunications,  information 
technology,  personnel,  data,  documentation  and  other  resources  which  collect,  record,  process,  store, 
communicate,  retrieve,  and  display  information.  [DoD92d]  More  than  one  system  or  parts  of  different  systems 
may  be  input  to  the  software  reengineering  activity.  "An  AIS  can  include  computer  software  only,  computer 
hardware  only,  or  any  combination  of  the  above"  [DoD92d]. 


Usage 

tunneled  into  Cl 
Input  on  Activity 
Input  on  Activity 
Input  on  Activity 
Input  on  Activity 
Input  on  Activity 
Input  on  Activity 
Input  on  Activity 
Input  on  Activity 
Input  on  Activity 
Input  on  Activity 
Input  on  Activity 
Input  on  Activity 


AO  (  Reengineer  System  )  in  Cl 

AO  (  Reengineer  System  )  in  C 10 

A1  (  Define  Project )  in  CIO 

A1  (  Define  Project )  in  Cl  1 

A1 1  (  Define  Objectives  )  in  Cl  1 

A12  ( Identify  Baseline  )  in  Cl  I 

A12  ( Identify  Baseline  )  in  C14 

A121  ( Identify  Existing  Application  Software  )  in  C14 

A122  ( Identify  Existing  Data  )  in  CI4 

A123  ( Identify  Existing  Technical  Infrastructure  )  in  C14 

A1 1  (  Define  Objectives  )  in  C17 

A1 1 1  (  Develop  Objectives  &  Success  Factors )  in  C17 


Available  Reengineering  Technology 


Available  Reengineering  Technology  identifies  proposed  methodologies  and  tools  available  for  automating 
software  reengineering.  The  Available  Reengineering  Technology  constrains  the  Reengineering  Project  Plan,  by 
impacting  the  Methodologies  and  Tools  available  for  automating  the  software  reengineering  effort.  It  also  impacts 
the  schedule  and  funding  by  the  training  nece.ssary  to  use  this  technology  and  the  productivity  improvements  in 
automating  the  software  reengineering  process.  Repositories  may  exist  that  provide  information  on  Available 
Reengineering  Technology. 


Usage 

tunneled  into  Cl 

Control  on  Activity  AO  (  Reengineer  System  )  in  Cl 

Control  on  Activity  AO  (  Reengineer  System  )  in  CIO 

Control  on  Activity  A1  (  Define  Project )  in  CIO 

Control  on  Activity  A1  (  Define  Project )  in  Cl  1 

Control  on  Activity  A1 1  (  Define  Objectives  )  in  Cl  1 

Control  on  Activity  A13  (  Define  Reengineering  Project  Plan  )  in  Cl  1 

Control  on  Activity  A12  ( Identify  Baseline  )  in  Cl  1 

Control  on  Activity  A13  (  Define  Reengineering  Project  Plan  )  in  CIS 

Control  on  Activity  A132  ( Identify  Methodologies  and  Tools  )  in  CIS 
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Control  on  Activity  A12  (  Identify  Baseline  )  in  C14 

Control  on  Activity  A122  ( Identify  Existing  Data )  in  C14 

Control  on  Activity  A121  ( Identify  Existing  Application  Software  )  in  C14 

Control  on  Activity  A123  ( Identify  Existing  Technical  Infrastructure  )  in  C14 

Control  on  Activity  A1 1  (  Define  Objectives  )  in  C17 

Control  on  Activity  A1 1 1  ( Develop  Objectives  &  Success  Factors  )  in  C17 

Control  on  Activity  A1 12  ( Identify  Metrics  )  in  CI7 

Control  on  Activity  A1 13  ( Identify  Risks  )  in  C17 


Baselined  AIS  Components 

The  selected  information  system  components  comprised  of  the  technical  infrastructure,  data,  application  software, 
and  all  associated  documentation  which  will  be  used  during  reverse  engineering. 


Usage 

Output  on  Activity  A1  ( Define  Project )  in  CIO 

Input  on  Activity  A2  ( Reverse  Engineer )  in  CIO 

Output  on  Activity  A12  ( Identify  Baseline  )  in  Cl  1 

Output  on  Activity  A1  (  Define  Project )  in  Cl  1 

Input  on  Activity  A13  (  Define  Reengineering  Project  Plan  )  in  Cl  1 

Input  on  Activity  A2  ( Reverse  Engineer )  in  C12 

Input  on  Activity  A21  ( Analyze  Documentation  )  in  Cl 2 

Input  on  Activity  A22  (  Analyze  Application  Software  )  in  C12 

Input  on  Activity  A23  (  Analyze  Data )  in  CI2 

Input  on  Activity  A24  (  Analyze  Technical  Infrastructure  )  in  C 1 2 

tunneled  into  C14 

Output  on  Activity  A12  ( Identify  Baseline  )  in  C14 

Appears  in  C14  in  Breakdown  Baselined  AIS  Compo::  Existing  Technica,  Existing  Applicat,  Existing  Data 
Input  on  Activity  A13  (  Define  Reengineering  Project  Plan  )  in  C15 
Control  on  Activity  A131  (  Develop  Reengineering  Strategy  )  in  CIS 
Control  on  Activity  A132  ( Identify  Methodologies  and  Tools  )  in  CIS 


Build  Components 


Constructed  system  parts  to  be  interfaced  during  the  Integrate  activity,  including  the  required  documentation 
summarizing  the  results  of  the  coding  phase.  Refer  to  DOD-STD-2167A,  the  proposed  DOD-STD-498  and 
subsequent  standards  for  guidelines  on  producing  these  documents. 


Usage 


Output  on  Activity  A33  ( Build  )  in  C13 

Input  on  Activity  A34  ( Integrate  )  in  Cl 3 

Input  on  Activity  A3S  ( Test  and  Evaluate )  in  C13 
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Build  Results 


A  description  of  the  results  of  the  Build  activity  either  confirming  that  the  Build  Components  have  been 
constructed  or  a  request  for  clarification  on  a  design  issue  that  is  preventing  the  completion  of  the  Build  activity. 


Usage 

Output  on  Activity  A33  (  Build  )  in  C13 
Input  on  Activity  A32  (  Design  )  in  Cl 3 


Business  Requirements 

Organizational  goals  and  the  user  identified  needs  for  the  reengineered  software  system.  Some  of  the.se 
requirements  may  be  met  in  existing  AIS,  while  others  may  have  to  be  implemented  as  part  of  the  new  system. 


Usage 

tunneled  into  Cl 

Input  on  Activity  AO  (  Reengineer  System  )  in  Cl 

Input  on  Activity  AO  (  Reengineer  System  )  in  CIO 

Input  on  Activity  A1  (  Define  Project )  in  CIO 

Input  on  Activity  A2  (  Reverse  Engineer )  in  CIO 

Input  on  Activity  A3  (  Forward  Engineer )  in  CIO 

Input  on  Activity  A1  (  Define  Project )  in  Cl  1 

Input  on  Activity  A1 1  (  Define  Objectives  )  in  Cl  1 

Input  on  Activity  A12  ( Identify  Baseline  )  in  Cl  1 

Input  on  Activity  A13  (  Define  Reengineering  Project  Plan  )  in  Cl  1 

Input  on  Activity  A2  (  Reverse  Engineer )  in  C12 

Input  on  Activity  A25  (  Reconcile  Extracted  Products  )  in  C12 

Input  on  Activity  A3  (  Forward  Engineer )  in  Cl 3 

Input  on  Activity  A31  (  Analyze  )  in  C13 

Input  on  Activity  A12  ( Identify  Baseline  )  in  C14 

Input  on  Activity  A121  ( Identify  Existing  Application  Software  )  in  C14 

Input  on  Activity  A122  ( Identify  Existing  Data  )  in  C14 

Input  on  Activity  A123  ( Identify  Existing  Technical  Infrastructure  )  in  C14 

Input  on  Activity  A13  (  Define  Reengineering  Project  Plan  )  in  C15 

Input  on  Activity  A134  (  Produce  Reengineering  Project  Plan  )  in  C15 

Input  on  Activity  A1 1  (  Define  Objectives  )  in  C17 

Input  on  Activity  A1 1 1  (  Develop  Objectives  &  Success  Factors  )  in  C17 
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Candidate  Reuse  Assets 


Assets,  the  Candidate  Re^e  Aspire  during  the  reengineering  effort.  Like  Reusable 

test  data,  tools,  lessons,  learned,  and  specifications.  These  candidate  ZVnTJn 

verification  and  validation  as  to  potential  usability  in  multiple  software  systems  ^  certification  program  for 


Usage 

Output  on  Activity 
tunneled  into  Cl 
Output  on  Activity 
Output  on  Activity 
Output  on  Activity 
Output  on  Activity 
Output  on  Activity 
Output  on  Activity 
Output  on  Activity 
Output  on  Activity 
Output  on  Activity 
Output  on  Activity 
Output  on  Activity 
Output  on  Activity 
Output  on  Activity 
Output  on  Activity 
Output  on  Activity 
Output  on  Activity 
Output  on  Activity 
Output  on  Activity 
Output  on  Activity 
Output  on  Activity 
Output  on  Activity 
Output  on  Activity 
Output  on  Activity 
Output  on  Activity 
Output  on  Activity 
Output  on  Activity 
Output  on  Activity 


AO  ( Reengineer  System  )  in  Cl 

A2  ( Reverse  Engineer  )  in  CIO 
A3  ( Forward  Engineer )  in  CIO 
A1  ( Define  Project )  in  CIO 
AO  ( Reengineer  System  )  in  CIO 
A25  ( Reconcile  Extracted  Products  )  in  Cl 2 
A2  ( Reverse  Engineer )  in  C12 
A31  (Analyze)  in  C13 
A32  ( Design  )  in  C13 
A33  (Build  )  in  C13 
A34  ( Integrate )  in  C13 
A35  ( Test  and  Evaluate )  in  C13 
A3  ( Forward  Engineer )  in  Cl 3 
A1 1  ( Define  Objectives )  in  Cl  1 
A12  ( Identify  Baseline )  in  Cl  1 

A13  ( Define  Reengineering  Project  Plan  )  in  Cl  1 
A1  ( Define  Project )  in  Cl  1 

t  loo  r Application  Software )  in  C14 
Alz2  ( Identify  Existing  Data  )  in  C14 

i  Technical  Infrastructure )  in  C14 

A12  ( Identify  Baseline  )  in  C14 

A131  ( Develop  Reengineering  Strategy  )  in  C15 
ZZ  Reengineering  Project  Plan  )  in  C15 

AI3  (  Define  Reengineering  Project  Plan  )  in  C15 

A I  lo  !  &  Success  Factors  )  in  C17 

At  12  ( Identify  Metrics  )  in  Cl 7 

A1 13  ( Identify  Risks  )  in  C17 

A1 1  ( Define  Objectives )  in  C17 
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Comp/Comm  Infrastructure 


A  service  utility  that  provides  common  shared  computing  and  communications  capabilities,  including  data  base, 
common  networks,  electronic  messaging,  and  computing  platforms. 


Usage 

tunneled  into  Cl 
Mechanism  on  Activity 
Mechanism  on  Activity 
Mechanism  on  Activity 
Mechanism  on  Activity 
Mechanism  on  Activity 
Mechanism  on  Activity 
Mechanism  on  Activity 
Mechanism  on  Activity 
Mechanism  on  Activity 
Mechanism  on  Activity 
Mechanism  on  Activity 
Mechanism  on  Activity 
Mechanism  on  Activity 
Mechanism  on  Activity 


AO  (  Reengineer  System  )  in  Cl 

AO  (  Reengineer  System  )  in  C 10 

A1  (  Define  Project )  in  CIO 

A3  (  Forward  Engineer  )  in  CIO 

A2  (  Reverse  Engineer )  in  CIO 

A1  (  Define  Project )  in  Cl  I 

A1 1  (  Define  Objectives  )  in  Cl  1 

A3  (  Forward  Engineer )  in  C13 

A34  ( Integrate  )  in  C13 

A35  (  Test  and  Evaluate  )  in  C13 

A2  (  Reverse  Engineer )  in  C12 

A24  (  Analyze  Technical  Infrastructure  )  in  C12 

A 1 1  (  Define  Objeeti ves  )  in  C 1 7 

A1 1 1  (  Develop  Objectives  &  Suecess  Factors  )  in  C17 


Computing/Communications  Infrastructure 

See  Comp/Comm  Infrastructure. 

Usage 

None 


Data 

Representation  of  facts,  concepts,  or  instructions  in  a  formalized  manner  suitable  for  communication, 
interpretation,  or  processing  by  humans  through  automatic  means  [DoD92b]. 

Usage 

None 
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Data  Model 

A  graphical  and  textual  representation  of  analysis  that  identifies  the  data  needed  by  an  organization  to  achieve  its 
mission,  functions,  goals,  objectives,  and  strategies  and  to  manage  and  operate  the  organization.  It  identifies  the 
data,  their  attributes,  and  relationships  or  associations  with  other  data.  Data  Models  include  the  logical,  physical, 
and/or  normalized  models. 

Ref.:  DoD  Technical  Architecture  Framework  for  Information  Management  (Architecture  Guidance  and  Design 
Concepts),  Version  1.1,  Vol.2,  Center  for  Information  Management,  Arlington  VA,  22204-2199,  October  1992. 


Usage 

None 


Design  Components 


Modules  representing  a  design  of  the  system  parts  to  be  constructed  during  the  Build  activity,  including  the 
required  documentation  summarizing  the  results  of  the  design  phase.  Refer  to  DOD-STD-2167A,  the  proposed 
DOD-STD-498  and  subsequent  standards  for  guidelines  on  producing  these  documents. 


Usage 

Output  on  Activity  A32  (  Design  )  in  C13 
Input  on  Activity  A33  (  Build  )  in  C13 


Design  Results 


A  description  of  the  results  of  the  Design  activity  either  confirming  that  the  Design  Components  have  been 
constructed  or  a  request  for  clarification  of  a  analysis  issue  that  is  preventing  the  completion  of  the  Design 
activity. 


Usage 

Output  on  Activity  A32  ( Design  )  in  C13 
Input  on  Activity  A31  ( Analyze  )  in  C13 
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DoD  Enterprise  Model 

The  DoD  Enterprise  Model  is  a  representation  of  the  activities  and  data  of  the  Department  of  Defense  (DoD) 
needed  to  accomplish  the  defense  mission,  from  warfighting  to  acquisition  and  logistics  support.  This  Model  is 
the  basis  for  defining,  coordinating  and  integrating  DoD  missions  and  functions.  It  enables  leaders  and  managers 
to  better  understand  and  direct  their  areas  of  responsibility,  and  to  integrate  functional  process  improvement 
initiatives  within  and  across  functional  and  organizational  boundaries. 

Ref.:  The  DoD  Enterprise  Model,  February  1994,  OASD(C3I),  1225  Jefferson  Davis  Highway,  Suite  910, 
Arlington,  VA  22202-4301. 


Usage 

tunneled  into  Cl 
Control  on  Activity 
Control  on  Activity 
Control  on  Activity 
Control  on  Activity 
Control  on  Activity 
Control  on  Activity 
Control  on  Activity 
Control  on  Activity 
Control  on  Activity 
Control  on  Activity 
Control  on  Activity 
Control  on  Activity 
Control  on  Activity 
Control  on  Activity 
Control  on  Activity 
Control  on  Activity 
Control  on  Activity 
Control  on  Activity 
Control  on  Activity 
Control  on  Activity 


AO  (  Reengineer  System  )  in  Cl 

AO  (  Reengineer  System  )  in  CIO 

A1  (  Define  Project )  in  CIO 

A2  (  Reverse  Engineer )  in  CIO 

A3  (  Forward  Engineer )  in  CIO 

A1  (  Define  Project )  in  Cl  1 

A1 1  (  Define  Objectives  )  in  Cl  1 

A13  (  Define  Reengineering  Project  Plan  )  in  Cl  1 

A2  (  Reverse  Engineer )  in  C12 

A2 1  (  Analyze  Documentation  )  in  C 1 2 

A22  (  Analyze  Application  Software  )  in  C12 

A23  (  Analyze  Data  )  in  C12 

A24  (  Analyze  Technical  Infrastructure  )  in  C12 

A25  (  Reconcile  Extracted  Products  )  in  CI2 

A3  (  Forward  Engineer )  in  C13 

A31  (  Analyze  )  in  C13 

A13  (  Define  Reengineering  Project  Plan  )  in  C15 
A131  (  Develop  Reengineering  Strategy  )  in  C15 
A1 1  (  Define  Objectives  )  in  C17 
A1 1 1  (  Develop  Objectives  &  Success  Factors  )  in  C17 


Existing  Application  Software 


Description  of  the  application  software  within  the  AIS  and  all  associated  documentation.  This  software  was 
developed  specifically  for  the  existing  automated  information  system  and  does  not  include  any  commercially 
produced  software. 


Usage 

Output  on  Activity  A121  ( Identify  Existing  Application  Software  )  in  CI4 
tunneled  into  C14 

Appears  in  C14  in  Breakdown  Baselined  AIS  Compo::  Existing  Technica,  Existing  Applicat,  Existing  Data 
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Existing  Data 

Description  of  the  data  utilized  within  the  AIS,  including  the  data  elements,  their  implemented  data  structure,  and 
all  associated  documentation. 


Usage 

Output  on  Activity  A122  ( Identify  Existing  Data  )  in  C14 
tunneled  into  C14 

Appears  in  C14  in  Breakdown  Baselined  AIS  Compo::  Existing  Technica,  Existing  Applicat,  Existing  Data 


Existing  Technical  Infrastructure 


Description  of  the  technical  infrastructure  portion  of  the  AIS.  This  infrastructure  may  include,  but  is  not  limited  to 
the  information  describing  the  capabilities  and  the  structure  of  the  hardware,  operating  system,  integrated 
Commercial-Off-the-Shelf  (COTS),  Government-Off-the-Shelf  (GOTS)  products,  and  non-developmental 
software. 


Usage 

Output  on  Activity  A123  ( Identify  Existing  Technical  Infrastructure  )  in  C14 
tunneled  into  C 14 

Appears  in  C14  in  Breakdown  Baselined  AIS  Compo:;  Existing  Technica,  Existing  Applicat,  Existing  Data 


Extracted  Data  Products 


These  products  may  include,  but  are  not  limited  to  data  models  and  the  information  needed  to  define  business 
rules,  design  models,  system  specifications,  functional  requirements,  process  models,  and  design  decisions,  and 
collect  metric  data. 


Usage 

Output  on  Activity  A23  ( Analyze  Data )  in  C12 

Input  on  Activity  A25  ( Reconcile  Extracted  Products  )  in  C12 
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Extracted  Documentation  Products 


These  products  may  include,  but  are  not  limited  to  the  information  needed  to  define  business  rules,  design  models, 
system  specifications,  technical  infrastructure  capabilities,  data  models,  process  models,  and  design  decisions. 


Usage 

Output  on  Activity  A21  (  Analyze  Documentation  )  in  C12 
Input  on  Activity  A25  (  Reconcile  Extracted  Products  )  in  C12 


Extracted  Software  Products 

These  produets  may  inelude,  but  are  not  limited  to  process  models  and  the  information  needed  to  define  busine.ss 
rules,  design  models,  system  specifications,  functional  requirements,  data  models,  and  design  decisions,  and 
collect  metric  data. 


Usage 

Output  on  Activity  A22  (  Analyze  Application  Software  )  in  C12 
Input  on  Activity  A25  (  Reconcile  Extracted  Products  )  in  C12 


Extracted  Technical  Infrastructure  Products 

These  products  may  include,  but  are  not  limited  to  a  description  of  the  technical  infrastructure  capabilities  and  the 
information  needed  to  collect  metric  data  and  define  design  decisions. 


Usage 

Output  on  Activity  A24  (  Analyze  Technical  Infrastructure  )  in  C12 
Input  on  Activity  A25  (  Reconcile  Extracted  Products  )  in  C12 
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Feasibility  Analysis  Results 


The  results  from  any  study  that  may  have  been  performed  prior  to  the  start  of  the  reengineering  project  to  scope 
the  feasibility  of  reengineering  should  be  used  as  input  to  the  reengineering  process.  These  results  may  identify 
and  explore  information  necessary  to  perform  the  reengineering  project.  The  results  of  this  analysis  should  be 
input  to  the  Software  Reengineering  Process  Model  and  the  members  of  the  Reengineering  Project  Team  should 
participate  in  the  performance  of  this  analysis. 

These  results  may  serve  as  controls  on  an  activity,  but  may  also  serve  as  inputs  which  are  consumed  and  altered  by 
an  activity,  including  new  business  requirements,  critical  success  factors,  and  objectives.  Therefore,  the  results 
from  any  feasibility  analysis  are  represented  as  an  input  to  the  Reengineer  System  activity. 

The  results  of  the  analysis  may  include,  but  are  not  limited  to  a  cost/benefit  analysis  results,  risk  analysis  and 
management,  and  a  technical  justification  for  the  reengineering.  The  cost/benefit  analysis  determines  the  cost  of 
performing  the  reengineering  compared  to  the  benefits  expected  from  reengineering.  The  technical  justification 
includes  a  description  of  how  the  reengineering  project  is  justified  based  on  the  technical  aspects  of  the  effort. 


Usage 

tunneled  into  Cl 

Input  on  Activity  AO  (  Reengineer  System  )  in  Cl 

Input  on  Activity  AO  ( Reengineer  System  )  in  CIO 

Input  on  Activity  A1  (  Define  Project )  in  CIO 

Input  on  Activity  A1  (  Define  Project )  in  Cl  1 

Input  on  Activity  A 1 1  (  Define  Objectives  )  in  C 1 1 

Input  on  Activity  A12  ( Identify  Baseline )  in  Cl  1 

Input  on  Activity  A13  (  Define  Reengineering  Project  Plan  )  in  Cl  1 

Input  on  Activity  A12  ( Identify  Baseline  )  in  C14 

Input  on  Activity  A121  ( Identify  Existing  Application  Software  )  in  C14 

Input  on  Activity  A122  ( Identify  Existing  Data )  in  C14 

Input  on  Activity  A123  ( Identify  Existing  Technical  Infrastructure  )  in  C14 

Input  on  Activity  A13  (  Define  Reengineering  Project  Plan  )  in  C15 

Input  on  Activity  A131  (  Develop  Reengineering  Strategy  )  in  C15 

Input  on  Activity  A132  ( Identify  Methodologies  and  Tools  )  in  CIS 

Input  on  Activity  A133  (  Allocate  Resources  )  in  CIS 

Input  on  Activity  A134  (  Produce  Reengineering  Project  Plan  )  in  CIS 

Input  on  Activity  A1 1  (  Define  Objectives  )  in  C17 

Input  on  Activity  A1 1 1  ( Develop  Objectives  &  Success  Factors  )  in  C17 


Functional  (Business)  Requirements 

Usage 

Output  on  Activity  A1  (  Perform  Functional  Process  Improvement )  in  CIS 
Input  on  Activity  A2  (  Perform  Technical  &  Economic  Analysis  )  in  CIS 
Input  on  Activity  A3  (  Develop  or  Reengineer  Systems  )  in  C 1 8 
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Information  Management 

(IM)  Information  Management  is  the  creation,  use,  sharing,  and  disposition  of  information  as  a  resource  critical  to 
the  effective  and  efficient  operation  of  functional  activities.  The  structuring  of  functional  processes  to  produce 
and  control  the  use  of  data  and  information  within  functional  activities,  information  systems,  and 
Computing/Communications  Infractructure.  [DoD92d] 

From  a  domain  analysis  perspective,  IM  would  provide  support  toa  domain  which  identifies  commonalities 
accross  applications  of  the  specific  business  or  technology  area. 

Information  Management  (IM)  Services  include  such  things  as  Tools,  Methodologies,  Repositories,  and 
Computing/Communications  Infrastructure. 

Usage 

None 


Integrated  Components 


The  interfaced  Build  Components  representing  part  or  all  of  the  system  to  be  tested  during  the  Test  &  Evaluate 
activity.  The  Integrated  Components  include  the  required  documentation  summarizing  the  re.sults  of  the  Integrate 
phase. 


Usage 

Output  on  Activity  A34  ( Integrate  )  in  C13 
Input  on  Activity  A35  (  Test  and  Evaluate  )  in  CI3 


Integration  Results 


A  description  of  the  results  of  the  Integrate  activity  either  confirming  that  the  Build  Components  have  been 
interfaced  successfully  or  a  request  for  clarification  on  an  interface  or  build  issue  that  is  preventing  the  completion 
of  the  Integrate  activity. 


Usage 

Output  on  Activity  A34  ( Integrate  )  in  Cl 3 
Input  on  Activity  A33  (  Build  )  in  C13 
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Methodologies 

The  systems  of  principles,  procedures,  and  practices  applied  to  the  project  definition,  development,  operation, 
reengineering  and  support  of  a  software  system.  Reengineering  methodologies  are  subdivided  into  project 
definition,  reverse  and  forward  engineering  methodologies.  These  methodologies  support  various  software 
engineering  methodologies,  which  should  be  carefully  investigated  to  ensure  efficient  technical  integration  into 
the  sponsoring  organization's  existing  software  engineering  environment. 


Usage 


tunneled  into  Cl 
Mechanism  on  Activity 
Mechanism  on  Activity 
Mechanism  on  Activity 
Mechanism  on  Activity 
Mechanism  on  Activity 
Mechanism  on  Activity 
Mechanism  on  Activity 
Mechanism  on  Activity 
Mechanism  on  Activity 
Mechanism  on  Activity 
Mechanism  on  Activity 
Mechanism  on  Activity 
Mechanism  on  Activity 
Mechanism  on  Activity 
Mechanism  on  Activity 
Mechanism  on  Activity 
Mechanism  on  Activity 
Mechanism  on  Activity 
Mechanism  on  Activity 
Mechanism  on  Activity 
Mechanism  on  Activity 
Mechanism  on  Activity 
Mechanism  on  Activity 
Mechanism  on  Activity 
Mechanism  on  Activity 
Mechanism  on  Activity 


AO  (  Reengineer  System  )  in  Cl 

AO  (  Reengineer  System  )  in  CIO 

A1  (  Define  Project )  in  CIO 

A2  (  Reverse  Engineer )  in  CIO 

A3  ( Forward  Engineer )  in  CIO 

A1  (  Define  Project )  in  Cl  1 

A12  ( Identify  Baseline  )  in  Cl  1 

A1 1  (  Define  Objectives  )  in  Cl  1 

A2  (  Reverse  Engineer )  in  Cl 2 

A21  (  Analyze  Documentation  )  in  C12 

A22  ( Analyze  Application  Software )  in  C12 

A23  ( Analyze  Data  )  in  C12 

A3  (  Forward  Engineer )  in  C13 

A31  ( Analyze  )  in  C13 

A32  (  Design  )  in  C13 

A33(  Build)  in  C13 

A34  ( Integrate  )  in  C13 

A35  (  Test  and  Evaluate )  in  C13 

A12  ( Identify  Baseline  )  in  C14 

A121  ( Identify  Existing  Application  Software  )  in 

A122  ( Identify  Existing  Data )  in  C14 

A123  ( Identify  Existing  Technical  Infrastructure  ) 

A1 1  (  Define  Objectives )  in  C17 

A1 1 1  (  Develop  Objectives  &  Success  Factors  )  in 

A1 12  ( Identify  Metrics  )  in  Cl 7 

A1 13  (Identify  Risks) in C17 


C14 

inC14 

C17 


Metrics 

Metrics  are  measurable  implements  which  can  be  used  to  predict,  monitor,  and  evaluate  the  success  of  the 
reengineering  project.  Metrics  should  be  identified  and  linked  to  the  Objectives  and  Critical  Success  Factors 
identified  for  each  individual  reengineering  project.  The  Goal/Question/Metrics  technique  is  often  used  to  assist 
in  identifying  Metrics  and  linking  the  Metrics  to  Objectives  [Basi93].  Example  Metrics  include  those  identified 
by  Carnegie  Melon  University's  Software  Engineering  Institute  (SEI)  as  initial  core  measures  [CMU92]  and  the 
DoD  Core  Metrics,  including  size,  effort,  defects,  and  schedule. 
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Usage 

Output  on  Activity  A1 1  (  Define  Objectives  )  in  Cl  1 
tunneled  into  Cl  1 

Appears  in  Cl  1  in  Breakdown  Metrics,  Objectives::  Risks,  Objectives,  Metrics 
Output  on  Activity  A1 12  ( Identify  Metrics  )  in  C17 
Output  on  Activity  A1 1  (  Define  Objectives  )  in  C17 


Metrics,  Objectives,  Risks 

See  Metrics,  Objectives,  and  Risks. 

Usage 

tunneled  into  Cl  1 

Input  on  Activity  A13  (  Define  Reengineering  Project  Plan  )  in  Cl  1 
Appears  in  Cl  1  in  Breakdown  Metrics,  Objectives::  Risks,  Objectives,  Metrics 
Input  on  Activity  A13  (  Define  Reengineering  Project  Plan  )  in  C15 
Input  on  Activity  A131  (  Develop  Reengineering  Strategy  )  in  CI5 
Input  on  Activity  A134  (  Produce  Reengineering  Project  Plan  )  in  CIS 
Input  on  Activity  A132  ( Identify  Methodologies  and  Tools  )  in  CIS 


New  or  Reengineered  System 

One  or  more  products  of  the  Develop  or  Reengineer  Systems  activity.  See  also  Reenigneered  System. 
Usage 

Output  on  Activity  A3  (  Develop  or  Reengineer  Systems  )  in  CIS 
Input  on  Activity  A4  (  Transition  to  Operation  &  Maintenance  )  in  CIS 
Input  on  Activity  AS  ( Implement,  Operate  &  Maintain  )  in  CIS 


Objectives 


Objectives  for  using  the  system  include  performance  issues  from  a  user's  perspective  and  the  user  interface.  The 
objectives  for  supporting  the  system  include  improvements  in  maintenance  and  extending  life  expectancy.  The 
objectives  of  utilizing  reengineering  technology  include  proof-of-concepts  and  identification  of  risks. 

Objectives  are  viewed  as  input  and  not  output,  since  these  are  desired  goals  of  the  reengineering  effort  which  are 
subject  to  change  based  on  actual  implementation  of  reengineering  technology.  Objectives  may  also  be 
funetional  or  technical  requirements  that  are  to  be  implemented  or  met  (as  performance  issues)  in  the 
Reengineered  System.  How  these  Objectives  are  addressed  during  the  reengineering  is  determined  as  part  of  the 
Reengineering  Project  Plan.  Recommended  Changes  to  Objectives  are  derived  from  the  Objectives. 
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Usage 

Control  on  Activity  A12  ( Identify  Baseline )  in  C14 

Control  on  Activity  A121  ( Identify  Existing  Application  Software  )  in  C14 

Control  on  Activity  A122  ( Identify  Existing  Data )  in  C14 

Control  on  Activity  A123  ( Identify  Existing  Technical  Infrastructure  )  in  C14 

Output  on  Activity  A1 1 1  (  Develop  Objectives  &  Success  Factors  )  in  C17 

Input  on  Activity  A1 13  ( Identify  Risks  )  in  C17 

Input  on  Activity  A1 12  ( Identify  Metrics  )  in  C17 

Output  on  Activity  A1 1  (  Define  Objectives )  in  C17 

Output  on  Activity  A1 1  (  Define  Objectives  )  in  Cl  1 

Control  on  Activity  A12  ( Identify  Baseline )  in  Cl  1 

Appears  in  Cl  1  in  Breakdown  Metrics,  Objectives::  Risks,  Objectives,  Metrics 


Operational  Experience 

Evidence  obtained  from  the  conduct  of  all  defense  activities,  cinluding  successes  and  failures  in  military 
operations,  that  represent  the  factual  basis  for  assessing  and  improving  the  direction  that  guides  Defense  activities 
[DoD94]. 


Usage 

Output  on  Activity  A5  ( Implement,  Operate  &  Maintain  )  in  Cl 8 
Input  on  Activity  A1  (  Perform  Functional  Process  Improvement )  in  Cl 8 
Input  on  Activity  A4  ( Transition  to  Operation  &  Maintenance  )  in  Cl 8 


Other  Models 


Representations  which  reflect  commonality  and  reuse  opportunities  in  a  group  of  similar  systems  identified  as  part 
of  a  particular  mission.  These  representations  include  such  things  as  descriptions  of  the  business  area,  data  items, 
objects,  business  rules,  and  the  organization  of  data  items  and  objects  by  business  rules  to  create  products.  There 
are  many  examples  of  these,  two  of  which  are  functional  area  models  and  domain  models. 


Usage 

tunneled  into  Cl 

Control  on  Activity  AO  (  Reengineer  System  )  in  Cl 

Control  on  Activity  AO  (  Reengineer  System  )  in  CIO 

Control  on  Activity  A1  (  Define  Project )  in  CIO 

Control  on  Activity  A2  (  Reverse  Engineer  )  in  CIO 

Control  on  Activity  A3  ( Forward  Engineer )  in  CIO 

Control  on  Activity  A1  (  Define  Project )  in  Cl  1 

Control  on  Activity  A1 1  (  Define  Objectives )  in  Cl  1 

Control  on  Activity  A13  ( Define  Reengineering  Project  Plan  )  in  Cl  1 

Control  on  Activity  A2  (  Reverse  Engineer  )  in  C12 

Control  on  Activity  A21  ( Analyze  Documentation  )  in  C12 
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Control 

Control 

Control 

Control 

Control 

Control 

Control 

Control 

Control 

Control 


on  Activity  A22  (  Analyze  Application  Software  )  in  C12 
on  Activity  A23  (  Analyze  Data  )  in  C12 
on  Activity  A24  (  Analyze  Technical  Infrastructure  )  in  C12 
on  Activity  A25  (  Reconcile  Extracted  Products  )  in  C12 
on  Activity  A3  (  Forward  Engineer )  in  C13 
on  Activity  A31  (  Analyze  )  in  C13 

on  Activity  A13  (  Define  Reengineering  Project  Plan  )  in  C15 
on  Activity  A131  (  Develop  Reengineering  Strategy  )  in  C15 
on  Activity  A1 1  (  Define  Objectives  )  in  C17 
on  Activity  A1 1 1  (  Develop  Objectives  &  Success  Factors  )  in  C17 


Portfolio  Analysis 

A  high-level  study  of  the  AIS  which  may  be  performed  to  define  the  Objectives. 
Usage 
None 


Process  Model 

A  graphical  and  textual  representation  for  organizing  the  data  and  processes  into  manageable  groups  to  facilitate 
their  shared  use  and  control  throughout  the  organization.  This  representation  provides  a  framework  for 
identifying,  defining,  and  organizing  business  strategies,  business  rules,  and  proces.ses  needed  to  manage  and 
support  the  way  an  organization  does  or  wants  to  do  business.  Process  Models  include  the  logical,  physical, 
and/or  normalized  models. 

Ref:  DoD  5000  1 1-M,  DoD  Data  Administration  Procedures,  Department  of  Manual,  June  1991. 


Usage 

None 

Project  Resources 

The  resources  for  this  reengineering  project,  including  personnel,  computer  resources,  and  tools.  These  resources 
must  remain  within  the  constraint  of  Resource  Limitations. 


Usage 

Output  on  Activity  A133  (  Allocate  Resources  )  in  Ci5 

Input  on  Activity  A134  (  Produce  Reengineering  Project  Plan  )  in  C15 
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Project  Team 


The  personnel  who  will  perform  the  reengineering  effort  form  a  team.  The  members  of  this  team  may  include,  but 
are  not  limited  to  experts  in  the  following  areas;  software/system  engineering,  technical  infrastructure, 
function/mission  of  the  system  domain,  users  of  the  application  software,  and  reengineering  technology. 
Specifically,  the  Project  Team  should  involve  the  functional  customer  as  much  as  possible  throughout  the 
reengineering  effort. 


Usage 

tunneled  into  Cl 

Mechanism  on  Activity  AO  ( Reengineer  System  )  in  Cl 

Mechanism  on  Activity  AO  (  Reengineer  System  )  in  CIO 

Mechanism  on  Activity  A1  (  Define  Project )  in  CIO 

Mechanism  on  Activity  A2  (  Reverse  Engineer )  in  CIO 

Mechanism  on  Activity  A3  ( Forward  Engineer )  in  CIO 

Mechanism  on  Activity  A1  (  Define  Project )  in  Cl  1 

Mechanism  on  Activity  A1 1  (  Define  Objectives  )  in  Cl  1 

Mechanism  on  Activity  A12  ( Identify  Baseline  )  in  Cl  1 

Mechanism  on  Activity  A13  ( Define  Reengineering  Project  Plan  )  in  Cl  1 

Mechanism  on  Activity  A2  (  Reverse  Engineer )  in  C12 

Mechanism  on  Activity  A21  (  Analyze  Documentation  )  in  C12 

Mechanism  on  Activity  A22  ( Analyze  Application  Software  )  in  C12 

Mechanism  on  Activity  A23  ( Analyze  Data )  in  C12 

Mechanism  on  Activity  A24  ( Analyze  Technical  Infrastructure  )  in  C12 

Mechanism  on  Activity  A25  ( Reconcile  Extracted  Products  )  in  Cl 2 

Mechanism  on  Activity  A3  ( Forward  Engineer )  in  C13 

Mechanism  on  Activity  A31  ( Analyze )  in  C13 

Mechanism  on  Activity  A32  ( Design  )  in  C13 

Mechanism  on  Activity  A33  (  Build  )  in  C13 

Mechanism  on  Activity  A34  ( Integrate  )  in  C13 

Mechanism  on  Activity  A35  (  Test  and  Evaluate )  in  C13 

Mechanism  on  Activity  A12  ( Identify  Baseline )  in  C14 

Mechanism  on  Activity  A121  ( Identify  Existing  Application  Software  )  in  C14 

Mechanism  on  Activity  A122  ( Identify  Existing  Data )  in  C14 

Mechanism  on  Activity  A123  ( Identify  Existing  Technical  Infrastructure  )  in  C14 

Mechanism  on  Activity  A13  ( Define  Reengineering  Project  Plan  )  in  C15 

Mechanism  on  Activity  A132  ( Identify  Methodologies  and  Tools  )  in  C15 

Mechanism  on  Activity  A133  (  Allocate  Resources  )  in  C15 

Mechanism  on  Activity  A134  ( Produce  Reengineering  Project  Plan  )  in  C15 

Mechanism  on  Activity  A131  ( Develop  Reengineering  Strategy  )  in  C15 

Mechanism  on  Activity  A1 1  ( Define  Objectives )  in  C17 

Mechanism  on  Activity  A1 1 1  ( Develop  Objectives  &  Success  Factors  )  in  C17 

Mechanism  on  Activity  A1 12  ( Identify  Metrics  )  in  C17 

Mechanism  on  Activity  A1 13  ( Identify  Risks )  in  C17 
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Proposed  Methodologies  and  Tools 


The  proposed  methodologies  and  tools  for  implementing  the  Reengineering  Project  Strategy.  The  Proposed 
Methodologies  and  Tools  are  defined  by  Available  Reengineering  Technology  according  to  the  characteri.stics  of 
the  Baseline  Automated  Information  System  and  must  be  within  available  resources  as  determined  by  Allocate 
Resources. 


Usage 

Output  on  Activity  A132  ( Identify  Methodologies  and  Tools  )  in  C15 
Input  on  Activity  A131  (  Develop  Reengineering  Strategy  )  in  CI5 
Input  on  Activity  A133  (  Allocate  Re.sources  )  in  C15 


Recommended  Changes  to  Baseline 

Recommended  Changes  to  Baseline  are  suggested  by  the  Produce  Reengineering  Project  Plan  activity.  The.se 
changes  scope  the  reengineering  effort  by  suggesting  an  alternative  baseline.  These  changes  usually  result  from 
limitations  resulting  from  the  Project  Strategy,  Project  Resources,  and  Proposed  Methodologies  and  Tools.  These 
changes  may  impact  the  software,  data,  or  technical  infra.structure  of  the  baseline. 

The  Develop  Reengineering  Project  Plan  may  send  Recommended  Changes  to  Baseline  based  on  information  in 
the  Project  Plan  Revisions  (Reverse  Engineered  Products  and  the  Analysis  Deliverables). 


Usage 

Output  on  Activity  A13  (  Define  Reengineering  Project  Plan  )  in  Cl  1 

Input  on  Activity  A12  ( Identify  Baseline  )  in  Cl  I 

Input  on  Activity  A12  ( Identify  Baseline  )  in  C14 

Input  on  Activity  A121  ( Identify  Existing  Application  Software  )  in  C14 

Input  on  Activity  A122  ( Identify  Existing  Data  )  in  C14 

Input  on  Activity  A123  ( Identify  Existing  Technical  Infrastructure  )  in  C14 

Output  on  Activity  A134  (  Produce  Reengineering  Project  Plan  )  in  C15 

Output  on  Activity  A13  (  Define  Reengineering  Project  Plan  )  in  C15 
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Recommended  Changes  to  Controls 

Recommended  changes  to  specific  controls  on  this  activity  resulting  from  experience  and  knowledge  gained  by 
performing  reengineering.  These  controls  may  include  any  of  the  following:  Regulations,  Policy,  Standards,  and 
Guidelines,  Other  Models,  Technical  Architectures,  and  DoD  Enterprise  Model. 

Recommended  changes  to  Regulations,  Policy,  Standards,  and  Guidelines  may  include  information  describing  the 
impact  of  certain  regulations,  policy,  standards,  and  guidelines  on  reengineering  which  may  necessitate 
modification  or  clarification  of  these  controls. 

Recommended  changes  to  Other  Models  may  include  new  business  practices  uncovered  during  reverse 
engineering  which  may  necessitate  clarification  or  enhancement  to  these  models. 

Recommended  changes  to  Technical  Architectures  may  include  lessons  learned  when  utilizing  the  technical 
architectures  during  reengineering  which  may  necessitate  clarification  or  modification  to  these  architectures. 

Recommended  changes  to  the  DoD  Enterprise  Model  may  include  information  gathered  during  the  reengineering 
process  which  supports  the  DoD  Enterprise  Model  or  broadens  its  use. 


Usage 

Output  on  Activity 
tunneled  into  Cl 
Output  on  Activity 
Output  on  Activity 
Output  on  Activity 
Output  on  Activity 
Output  on  Activity 
Output  on  Activity 
Output  on  Activity 
Output  on  Activity 
Output  on  Activity 
Output  on  Activity 
Output  on  Activity 
Output  on  Activity 
Output  on  Activity 
Output  on  Activity 
Output  on  Activity 
Output  on  Activity 
Output  on  Activity 
Output  on  Activity 


AO  (  Reengineer  System  )  in  Cl 

A1  (  Define  Project )  in  CIO 

A2  (  Reverse  Engineer )  in  CIO 

A3  (  Forward  Engineer )  in  CIO 

AO  ( Reengineer  System  )  in  CIO 

A13  (  Define  Reengineering  Project  Plan  )  in  Cl  1 

A1  ( Define  Project )  in  Cl  1 

A25  (  Reconcile  Extracted  Products )  in  Cl 2 

A2  (  Reverse  Engineer )  in  C12 

A31  (  Analyze  )  in  C13 

A32  (  Design  )  in  C13 

A33(  Build)  in  C13 

A34  ( Integrate  )  in  C13 

A35  ( Test  and  Evaluate  )  in  C13 

A3  ( Forward  Engineer )  in  Cl 3 

A131  (  Develop  Reengineering  Strategy  )  in  C15 

A132  ( Identify  Methodologies  and  Tools  )  in  C15 

A134  (  Produce  Reengineering  Project  Plan  )  in  C15 

A13  ( Define  Reengineering  Project  Plan  )  in  C15 
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Recommended  Changes  to  Objectives 

Recommended  Changes  to  Objectives  are  suggested  by  the  Develop  Reengineering  Project  Plan  activity  and  result 
from  attempts  to  adequately  address  these  Objectives  in  the  Reengineering  Project  Plan.  These  changes  usually 
result  from  limitations  resulting  from  the  Project  Strategy,  Project  Resources,  and  Proposed  Methodologies  and 
Tools. 

The  Develop  Reengineering  Project  Plan  may  send  Recommended  Changes  to  Objectives  based  on  information  in 
the  Reverse  Engineered  Products,  Analysis  Deliverables,  metrics,  and  risks. 

Recommended  Changes  to  Objectives  are  derived  directly  from  the  Objectives. 


Usage 

Output  on  Activity  A13  (  Define  Reengineering  Project  Plan  )  in  Cl  1 

Input  on  Activity  A1 1  (  Define  Objectives  )  in  Cl  1 

Output  on  Activity  A134  (  Produce  Reengineering  Project  Plan  )  in  C15 

Output  on  Activity  A13  (  Define  Reengineering  Project  Plan  )  in  C15 

Input  on  Activity  A1 1  (  Define  Objectives  )  in  C17 

Input  on  Activity  A1 1 1  (  Develop  Objectives  &  Success  Factors  )  in  C17 


Recommended  Product  Revisions 

Recommended  Product  Revisions  are  generated  during  the  Reconcile  Extracted  Products  activity  when  an 
inconsistency  is  detected  between  one  or  more  of  the  following:  Extracted  Documentation  Products,  Extracted 
Software  Products,  Extracted  Data  Products,  and  Extracted  Technical  Infrastructure  Products.  These 
inconsistencies  must  be  corrected  before  these  products  can  be  considered  Reverse  Engineered  Products. 


Usage 

Output  on  Activity  A25  (  Reconcile  Extracted  Products  )  in  C12 
Input  on  Activity  A21  (  Analyze  Documentation  )  in  C12 
Input  on  Activity  A22  (  Analyze  Application  Software  )  in  C12 
Input  on  Activity  A23  (  Analyze  Data  )  in  C12 
Input  on  Activity  A24  (  Analyze  Technical  Infrastructure  )  in  C12 


Reengineered  System 

The  reengineered  system  is  generated  from  the  reengineering  activities  described  within  this  model.  It  consists  of 
software,  data,  technical  infrastructure,  test  results,  and  all  associated  documentation. 


Usage 

Output  on  Activity  AO  (  Reengineer  System  )  in  Cl 
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tunneled  into  Cl 

Output  on  Activity  A3  ( Forward  Engineer )  in  CIO 
Output  on  Activity  AO  (  Reengineer  System  )  in  CIO 
Output  on  Activity  A35  ( Test  and  Evaluate  )  in  Cl 3 
Output  on  Activity  A3  ( Forward  Engineer )  in  Cl 3 


Reengineering  Project  Plan 


The  Reengineering  Project  Plan  documents  the  Objectives,  identifies  the  Baselined  AIS  Components,  the  Project 
Resources,  and  Project  Strategy.  This  plan  includes  refined  feasibility  analysis  results,  risk  analysis/management 
information,  and  a  formalization  of  the  Business  Requirements  for  the  Reengineered  System.  The  requirements 
available  in  the  Baselined  AIS  Components  are  confirmed  through  the  reverse  engineering  process  and  those  to  be 
implemented  during  forward  engineering  are  identified  as  part  of  the  Analysis  Deliverables. 

The  Reengineering  Project  plan  defines  the  Objectives  and  depicts  how  the  reengineering  will  meet  these 
objectives.  The  Plan  includes  critical  success  factors  and  markers  for  proving  these  factors  were  achieved.  The 
Plan  also  outlines  how  the  Business  Requirements  map  to  the  specified  requirements  for  the  reengineered  system. 


Usage 

Output  on  Activity  A1  (  Define  Project )  in  CIO 

Control  on  Activity  A2  (  Reverse  Engineer )  in  CIO 

Control  on  Activity  A3  ( Forward  Engineer )  in  CIO 

Output  on  Activity  A13  (  Define  Reengineering  Project  Plan  )  in  Cl  1 

Output  on  Activity  A 1  (  Define  Project )  in  C 1 1 

Control  on  Activity  A2  (  Reverse  Engineer )  in  C12 

Control  on  Activity  A21  ( Analyze  Documentation  )  in  C12 

Control  on  Activity  A22  (  Analyze  Application  Software  )  in  C12 

Control  on  Activity  A23  ( Analyze  Data  )  in  C12 

Control  on  Activity  A24  (  Analyze  Technical  Infrastructure )  in  C12 

Control  on  Activity  A25  (  Reconcile  Extracted  Products  )  in  C12 

Control  on  Activity  A3  ( Forward  Engineer )  in  C13 

Control  on  Activity  A31  (  Analyze  )  in  C13 

Control  on  Activity  A32  (  Design  )  in  C13 

Control  on  Activity  A33  (  Build  )  in  C13 

Control  on  Activity  A34  ( Integrate  )  in  C13 

Control  on  Activity  A35  ( Test  and  Evaluate  )  in  Cl 3 

Output  on  Activity  A134  (  Produce  Reengineering  Project  Plan  )  in  C15 

Output  on  Activity  A13  (  Define  Reengineering  Project  Plan  )  in  CIS 
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Reengineering  Project  Strategy 

Description  of  how  the  automated  information  system  will  be  reengineered.  The  Reengineering  Project  Strategy 
includes  the  identification  and  integration  of  reengineering  methodologies  into  a  cohesive  strategy  for 
accomplishing  the  organizational  goals  of  the  reengineering  project.  The  strategy  drives  the  identification  and 
utilization  of  tools  to  automate  the  reengineering.  The  strategy  also  identifies  and  describes  a  risk  mitigation 
strategy  and  the  structure  of  the  products  expected  from  the  reengineering.  This  strategy  also  includes 
certification  procedures  for  evaluating  the  Test  Results  during  the  Test  &  Evaluate  activity. 

The  Reengineering  Project  Strategy  identifies  reengineering  alternatives  which  include  scenarios,  possible 
incorporation  of  new  technology  and  approaches,  and  the  use  of  methodologies  and  tools.  Possible  scenarios 
include,  but  are  not  limited  to  restructuring,  redocumentation,  and  data  rationalization. 

Usage 

Output  on  Activity  A131  (  Develop  Reengineering  Strategy  )  in  C15 
Input  on  Activity  AI33  (  Allocate  Resources  )  in  CI5 
Control  on  Activity  A132  ( Identify  Methodologies  and  Tools  )  in  C15 
Input  on  Activity  AI34  (  Produce  Reengineering  Project  Plan  )  in  CIS 


Regs, Policy, Stds, Guidelines 


Documents  containing  the  principle  rules  designed  for  governing  and  influencing  decisions  and  actions  during 
software  engineering  activities.  There  are  many  such  documents,  two  of  which  are  the  Software  Reengineering 
Risks  Taxonomy  and  the  Information  Systems  Criteria  for  Applying  Software  Reengineering. 


Usage 

tunneled  into  Cl 

Control  on  Activity  AO  (  Reengineer  System  )  in  Cl 

Control  on  Activity  AO  (  Reengineer  System  )  in  CIO 

Control  on  Activity  A1  (  Define  Project )  in  CIO 

Control  on  Activity  A2  (  Reverse  Engineer  )  in  CIO 

Control  on  Activity  A3  (  Forward  Engineer )  in  CIO 

Control  on  Activity  A1  (  Define  Project )  in  Cl  1 

Control  on  Activity  A1 1  (  Define  Objectives  )  in  Cl  1 

Control  on  Activity  A13  (  Define  Reengineering  Project  Plan  )  in  Cl  1 

Control  on  Activity  A2  (  Reverse  Engineer )  in  C12 

Control  on  Activity  A21  (  Analyze  Documentation  )  in  C12 

Control  on  Activity  A22  (  Analyze  Application  Software  )  in  C12 

Control  on  Activity  A23  (  Analyze  Data  )  in  C12 

Control  on  Activity  A24  (  Analyze  Technical  Infrastructure  )  in  C12 

Control  on  Activity  A25  (  Reconcile  Extracted  Products  )  in  C12 

Control  on  Activity  A3  ( Forward  Engineer )  in  C13 

Control  on  Activity  A31  (  Analyze  )  in  C13 

Control  on  Activity  A32  (  Design  )  in  C13 

Control  on  Activity  A33  (  Build  )  in  C13 
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Control  on  Activity  A34  (  Integrate  )  in  C13 

Control  on  Activity  A35  ( Test  and  Evaluate  )  in  Cl 3 

Control  on  Activity  A13  (  Define  Reengineering  Project  Plan  )  in  C15 

Control  on  Activity  A134  ( Produce  Reengineering  Project  Plan  )  in  C15 

Control  on  Activity  A1 1  ( Define  Objectives  )  in  C17 

Control  on  Activity  A1 1 1  ( Develop  Objectives  &  Success  Factors  )  in  C17 

Control  on  Activity  A1 12  ( Identify  Metrics  )  in  C17 

Control  on  Activity  A1 13  ( Identify  Risks  )  in  C17 


Regulations,  Policy,  Standards,  Guidelines 

See  Regs,  Policy,  Stds,  Guidelines. 

Usage 

None 


Repositories 


A  mechanism  for  storing  and  retrieving  information  or  reusable  assets.  Examples  of  repositories  include  the 
Defense  Software  Repository  System  (DSRS),  DoD  Data  Repository  System  (DDRS),  Integrated  Computer-Aided 
Software  Engineering  G-CASE),  and  DoD  IDEE  Repositories.  The  DDRS  and  the  DSRS  are  managed  by  the 
CIM  Data  Administration  Program  Office  and  the  Reuse  Program  Office  respectively.  The  DoD  IDEF  Repository 
is  managed  by  the  CIM  Center  for  Expertise  in  FPL  Repository-based  technology  may  also  be  used  to  store  and 
retrieve  information  generated  during  the  reengineering  project,  including  Reverse  Engineered  Products  and  the 
Reengineered  System  components. 


Usage 

tunneled  into  Cl 

Mechanism  on  Activity  AO  (  Reengineer  System  )  in  Cl 

Mechanism  on  Activity  AO  (  Reengineer  System  )  in  CIO 

Mechanism  on  Activity  A1  (  Define  Project )  in  CIO 

Mechanism  on  Activity  A2  (  Reverse  Engineer )  in  CIO 

Mechanism  on  Activity  A3  ( Forward  Engineer )  in  CIO 

Mechanism  on  Activity  A1  ( Define  Project )  in  Cl  1 

Mechanism  on  Activity  A12  ( Identify  Baseline  )  in  Cl  1 

Mechanism  on  Activity  A13  (  Define  Reengineering  Project  Plan  )  in  Cl  1 

Mechanism  on  Activity  A1 1  (  Define  Objectives )  in  Cl  1 

Mechanism  on  Activity  A2  (  Reverse  Engineer )  in  C12 

Mechanism  on  Activity  A22  ( Analyze  Application  Software  )  in  C12 

Mechanism  on  Activity  A23  (  Analyze  Data )  in  C12 

Mechanism  on  Activity  A21  ( Analyze  Documentation  )  in  C12 

Mechanism  on  Activity  A25  ( Reconcile  Extracted  Products )  in  C12 

Mechanism  on  Activity  A3  ( Forward  Engineer )  in  C13 

Mechanism  on  Activity  A31  (  Analyze  )  in  C13 

Mechanism  on  Activity  A32  (  Design  )  in  C13 
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Mechanism 

Mechanism 

Mechanism 

Mechanism 

Mechanism 

Mechanism 

Mechanism 

Mechanism 

Mechanism 

Mechanism 

Mechanism 

Mechanism 

Mechanism 

Mechanism 

Mechanism 


on  Activity  A33  (  Build  )  in  C13 

on  Activity  A34  ( Integrate  )  in  C13 

on  Activity  A35  (  Test  and  Evaluate  )  in  C13 

on  Activity  A12  ( Identify  Baseline )  in  C14 

on  Activity  A121  ( Identify  Existing  Application  Software )  in  C14 

on  Activity  A122  ( Identify  Existing  Data )  in  C14 

on  Activity  A123  ( Identify  Existing  Technical  Infrastructure  )  in  C14 

on  Activity  A13  (  Define  Reengineering  Project  Plan  )  in  C15 

on  Activity  A131  (  Develop  Reengineering  Strategy  )  in  C15 

on  Activity  A132  ( Identify  Methodologies  and  Tools  )  in  C15 

on  Activity  A134  (  Produce  Reengineering  Project  Plan  )  in  C15 

on  Activity  A1 1  (  Define  Objectives  )  in  C17 

on  Activity  At  1 1  (  Develop  Objectives  &  Success  Factors  )  in  C 17 

on  Activity  An2  ( Identify  Metrics  )  in  C17 

on  Activity  A1 13  ( Identify  Risks  )  in  C17 


Resource  Limitations 

Estimated  limitations  on  available  resources,  including  manpower,  funding,  scheduling  deadlines,  computer 
resources,  and  skill  levels  for  performing  the  reengineering. 


Usage 


tunneled  into  Cl 

Control  on  Activity  AO  (  Reengineer  System  )  in  Cl 

Control  on  Activity  AO  (  Reengineer  System  )  in  CIO 

Control  on  Activity  A1  (  Define  Project )  in  CIO 

Control  on  Activity  A1  (  Define  Project )  in  Cl  1 

Control  on  Activity  A 1 1  (  Define  Objectives  )  in  C 1 1 

Control  on  Activity  A13  (  Define  Reengineering  Project  Plan  )  in  Cl 

Control  on  Activity  A13  (  Define  Reengineering  Project  Plan  )  in  Cl 

Control  on  Activity  A133  (  Allocate  Resources  )  in  C15 

Control  on  Activity  A1 1  (  Define  Objectives  )  in  C17 

Control  on  Activity  A1 1 1  (  Develop  Objectives  &  Success  Factors  ) 

Control  on  Activity  A1 13  ( Identify  Risks  )  in  C17 

Control  on  Activity  A1 12  ( Identify  Metrics  )  in  C17 


1 

5 


inC17 


Reusable  Assets 


Reusable  assets  are  software  work  products,  including  source  code,  documentation,  designs,  test  data,  tools,  and 
specifications.  Reusable  assets  are  stored  in  repositories  and  should  be  explored  for  use  throughout  the  software 
reengineering  effort. 
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Usage 

tunneled  into  Cl 

Input  on  Activity  AO  ( Reengineer  System  )  in  Cl 

Input  on  Activity  AO  (  Reengineer  System  )  in  CIO 

Input  on  Activity  A2  ( Reverse  Engineer )  in  CIO 

Input  on  Activity  A3  ( Forward  Engineer  )  in  CIO 

Input  on  Activity  A1  (  Define  Project )  in  CIO 

Input  on  Activity  A2  ( Reverse  Engineer )  in  C12 

Input  on  Activity  A22  ( Analyze  Application  Software  )  in  C 1 2 

Input  on  Activity  A23  ( Analyze  Data )  in  C12 

Input  on  Activity  A3  ( Forward  Engineer )  in  C 1 3 

Input  on  Activity  A31  (  Analyze  )  in  Cl 3 

Input  on  Activity  A32  (  Design  )  in  C13 

Input  on  Activity  A33  (  Build  )  in  C13 

Input  on  Activity  A34  ( Integrate  )  in  Cl 3 

Input  on  Activity  A35  (  Test  and  Evaluate  )  in  C13 

Input  on  Activity  A1  (  Define  Project )  in  Cl  1 

Input  on  Activity  A1 1  (  Define  Objectives  )  in  Cl  1 

Input  on  Activity  A13  (  Define  Reengineering  Project  Plan  )  in  Cl  1 

Input  on  Activity  A13  (  Define  Reengineering  Project  Plan  )  in  CIS 

Input  on  Activity  A131  (  Develop  Reengineering  Strategy  )  in  CIS 

Input  on  Activity  A134  (  Produce  Reengineering  Project  Plan  )  in  CIS 

Input  on  Activity  A132  ( Identify  Methodologies  and  Tools  )  in  CIS 

Input  on  Activity  A1 1  (  Define  Objectives  )  in  C17 

Input  on  Activity  A1 1 1  (  Develop  Objectives  &  Success  Factors  )  in  C17 

Input  on  Activity  A1 13  ( Identify  Risks  )  in  C17 

Input  on  Activity  A1 12  ( Identify  Metrics  )  in  C17 


Reverse  Engineered  Products 


Products  resulting  from  the  reverse  engineering  effort  which  are  used  in  the  forward  engineering  process.  These 
products  include,  but  are  not  limited  to  the  business  rules,  refined  feasibility  analysis  results,  updated  risk  analysis, 
design  model,  system  specification,  functional  requirements,  metric  data,  data  models,  process  models,  design 
decisions.  Reverse  engineered  products  reveal  the  business  requirements  fulfilled  by  the  existing  AIS. 

The  Reverse  Engineered  Products  also  provide  information  to  the  Define  Project  activity  which  impacts  the 
Reengineering  Project  Plan.  All  of  the  business  requirements  implemented  in  the  existing  AIS  may  not  be  known 
at  the  start  of  the  reengineering  effort.  The  business  rules  fulfilled  in  the  existing  AIS  are  determined  as  a  result  of 
the  Reverse  Engineer  activity.  The  Reverse  Engineered  Products  are  provided  to  the  Define  Project  activity  for 
updating  the  Reengineering  Project  Plan. 


Usage 

Output  on  Activity  A2  ( Reverse  Engineer )  in  CIO 
Input  on  Activity  A1  (  Define  Project )  in  CIO 
Input  on  Activity  A3  (  Forward  Engineer  )  in  CIO 
Input  on  Activity  A1  (  Define  Project )  in  Cl  I 
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tunneled  into  Cl  1 

Appears  in  Cl  1  in  Breakdown  Analysis  Del.,  Rev  Reverse  Engineere,  Analysis  Delivera 

Output  on  Activity  A25  (  Reconcile  Extracted  Products  )  in  C12 

Output  on  Activity  A2  (  Reverse  Engineer )  in  CI2 

Input  on  Activity  A3  (  Forward  Engineer )  in  Cl 3 

Input  on  Activity  A31  (  Analyze  )  in  Cl 3 

Input  on  Activity  A32  (  Design  )  in  C13 

Output  on  Activity  A3  (  Develop  or  Reengineer  Systems  )  in  CIS 
Input  on  Activity  A1  (  Perform  Functional  Process  Improvement )  in  CIS 
Input  on  Activity  A2  (  Perform  Technical  &  Economic  Analysis  )  in  CIS 


Revision  to  Project  Resources 

Recommended  changes  to  the  Project  Resources  based  on  constraints  from  Regulations,  Policy,  Standards,  and 
Guidelines  or  an  inability  to  reconcile  these  Resources  to  the  Reengineering  Strategy  and/or  Methodologies  and 
Tools. 


Usage 

tunneled  into  C15 

Input  on  Activity  A1 33  (  Allocate  Re.sources  )  in  C 15 

Appears  in  C15  in  Breakdown  Revisions  to  Projec;:  Revision  to  Proje,  Revision  to  Propo,  Revision  to  Reeng 


Revision  to  Proposed  Methodologies  and  Tools 

Recommended  changes  to  the  Selected  Methodologies  and  Tools  based  on  constraints  from  Regulations,  Policy, 
Standards,  and  Guidelines  or  an  inability  to  reconcile  the  Methodologies  and  Tools  to  the  Project  Budget  and/or 
Reengineering  Project  Strategy. 


Usage 

tunneled  into  C15 

Input  on  Activity  A132  ( Identify  Methodologies  and  Tools  )  in  C15 

Appears  in  C15  in  Breakdown  Revisions  to  Projec::  Revision  to  Proje,  Revision  to  Propo,  Revision  to  Reeng 


Revision  to  Reengineering  Strategy 

Request  for  a  revision  to  the  Reengineering  Strategy  based  on  constraints  from  Regulations,  Policy,  Standards, 
and  Guidelines  or  an  inability  to  reconcile  the  Reengineering  Strategy  to  the  Project  Budget  and/or  Methodologies 
and  Tools. 


4-40 


Project:  SAV  Systems  Reengineering;  Date:  12/19/94 


Usage 

tunneled  into  C15 

Input  on  Activity  A131  (  Develop  Reengineering  Strategy  )  in  C15 

Appears  in  CIS  in  Breakdown  Revisions  to  Projec;;  Revision  to  Proje,  Revision  to  Propo,  Revision  to  Reeng 


Revisions  to  Project  Plan 

See  individual  definitions  for  Revisions  to  Project  Resources,  Revisions  to  Proposed  Methodologies  and  Tools, 
and  Revisions  to  Reengineering  Strategy. 


Usage 

Output  on  Activity  A134  (  Produce  Reengineering  Project  Plan  )  in  CIS 
tunneled  into  CIS 

Appears  in  CIS  in  Breakdown  Revisions  to  Projec;:  Revision  to  Proje,  Revision  to  Propo,  Revision  to  Reeng 


Risks 

The  Software  Reengineering  Risks  Taxonomy  cites  several  definitions  for  risk  and  outlines  a  taxonomy  for 
identifying  and  categorizing  software  reengineering  risks.  For  the  purposes  of  this  Model,  a  risk  is  defined  as  a 
description  of  any  event  which  may  jeopardize  the  success  of  the  reengineering  project  if  it  occurs.  Each  risk 
should  be  identified,  and  plans  outlined  to  mitigate  this  risk  should  it  occur. 

Usage 

Output  on  Activity  A1 13  ( Identify  Risks )  in  C17 
Output  on  Activity  A1 1  (  Define  Objectives )  in  C17 
Output  on  Activity  A1 1  (  Define  Objectives  )  in  Cl  1 
tunneled  into  Cl  1 

Appears  in  Cl  1  in  Breakdown  Metrics,  Objectives::  Risks,  Objectives,  Metrics 


Technical  Architectures 

Representation  of  the  structure  of  technical  infrastructure  components,  including  computer  platforms,  support 
software,  and  communications;  their  relationships  and  interactions. 


Usage 

tunneled  into  Cl 

Control  on  Activity  AO  ( Reengineer  System  )  in  Cl 
Control  on  Activity  AO  ( Reengineer  System  )  in  CIO 
Control  on  Activity  A1  (  Define  Project )  in  CIO 
Control  on  Activity  A3  ( Forward  Engineer )  in  CIO 
Control  on  Activity  A1  (  Define  Project )  in  Cl  1 
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Control 

Control 

Control 

Control 

Control 

Control 

Control 

Control 

Control 

Control 


on  Activity  A1 1  (  Define  Objectives  )  in  Cl  1 

on  Activity  A13  (  Define  Reengineering  Project  Plan  )  in  Cl  1 

on  Activity  A3  (  Forward  Engineer  )  in  C13 

on  Activity  A31  (  Analyze  )  in  C13 

on  Activity  A32  (  Design  )  in  C13 

on  Activity  A13  (  Define  Reengineering  Project  Plan  )  in  C15 
on  Activity  A131  (  Develop  Reengineering  Strategy  )  in  C15 
on  Activity  A1 1  (  Define  Objectives  )  in  C17 
on  Activity  A1 1 1  (  Develop  Objectives  &  Success  Factors  )  in  C17 
on  Activity  A 1 1 3  ( Identify  Risks  )  in  C 1 7 


Technical  Improvement  Opportunities 

Technical  Improvement  Opportunities  may  result  from  technology  changes  identified  in  the  Perform  Technical  & 
Economic  Analysis  activity. 

Usage 

Output  on  Activity  A2  (  Perform  Technical  &  Economic  Analysis  )  in  CIS 
Input  on  Activity  A1  (  Perform  Functional  Process  Improvement )  in  CIS 


Technical  Infrastructure 

The  basic  facilities,  equipment  and  installations  needed  for  the  function  of  a  system  [DoD92b].  Sec  also  Existing 
Technical  Infrastructure. 

Usage 

None 


Technical  Requirements 

Technical  Requirements  are  those  technical  changes  identified  in  the  Perform  Technical  &  Economic  Analysis 
activity  which  are  designated  for  the  New  or  Reengineered  Systems. 

Usage 

Output  on  Activity  A2  (  Perform  Technical  &  Economic  Analysis  )  in  CIS 
Input  on  Activity  A3  (  Develop  or  Reengineer  Systems  )  in  CIS 


Test  Results 


Required  documentation  summarizing  the  results  of  the  testing  phase.  Refer  to  DOD-STD-2167A,  the  proposed 
DOD-STD-498  and  subsequent  standards  for  guidelines  on  producing  these  documents. 
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Usage 

Output  on  Activity  A35  ( Test  and  Evaluate  )  in  C13 
Input  on  Activity  A31  (  Analyze )  in  C13 
Input  on  Activity  A32  (  Design  )  in  C13 
Input  on  Activity  A33  (  Build  )  in  C13 
Input  on  Activity  A34  ( Integrate  )  in  Cl 3 


Tools 


Automated  and  manual  implements  used  to  improve  productivity  in  performing  or  accomplishing  the  activities. 
These  tools  should  integrate  into  the  sponsoring  organization's  software  engineering  environment.  Several- 
organizations  currently  support  tool  evaluation  and  should  be  contacted  to  support  the  selection  of  tools 
appropriate  for  the  individual  needs  of  the  reengineering  project. 

Reengineering  tools  can  be  described  in  several  categories,  including: 

project  management 
restructuring 
reverse  engineering 
source  code  analyzers 
design  recovery 
redocumentation 
forward  engineering 
code  generators 
requirements  analysis 
design  support  tools 
test  case  generators 
integration  support  tools 


Usage 


tunneled  into  Cl 
Mechanism  on  Activity 
Mechanism  on  Activity 
Mechanism  on  Activity 
Mechanism  on  Activity 
Mechanism  on  Activity 
Mechanism  on  Activity 
Mechanism  on  Activity 
Mechanism  on  Activity 
Mechanism  on  Activity 
Mechanism  on  Activity 
Mechanism  on  Activity 
Mechanism  on  Activity 
Mechanism  on  Activity 
Mechanism  on  Activity 


AO  (  Reengineer  System  )  in  Cl 

AO  (  Reengineer  System  )  in  CIO 

A1  (  Define  Project )  in  CIO 

A2  (  Reverse  Engineer )  in  CIO 

A3  ( Forward  Engineer )  in  CIO 

A1  (  Define  Project )  in  Cl  1 

A1 1  (  Define  Objectives )  in  C 1 1 

A12  ( Identify  Baseline )  in  Cl  1 

A13  ( Define  Reengineering  Project  Plan  )  in  Cl  1 

A2  (  Reverse  Engineer )  in  C12 

A21  (  Analyze  Documentation  )  in  C12 

All  ( Analyze  Application  Software )  in  C12 

A23  (  Analyze  Data  )  in  C12 

A24  ( Analyze  Technical  Infrastructure  )  in  C12 
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Mechanism 

Mechanism 

Mechanism 

Mechanism 

Mechanism 

Mechanism 

Mechanism 

Mechanism 

Mechanism 

Mechanism 

Mechanism 

Mechanism 

Mechanism 

Mechanism 

Mechanism 

Mechanism 

Mechanism 

Mechanism 

Mechanism 

Mechanism 


on  Activity  A25  (  Reconcile  Extracted  Products  )  in  CI2 

on  Activity  A3  (  Forward  Engineer  )  in  C13 

on  Activity  A31  (  Analyze  )  in  C13 

on  Activity  A32  (  Design  )  in  C13 

on  Activity  A33  (  Build  )  in  C13 

on  Activity  A34  ( Integrate  )  in  C13 

on  Activity  A35  (  Test  and  Evaluate  )  in  C13 

on  Activity  A12  ( Identify  Baseline  )  in  C14 

on  Activity  A121  ( Identify  Existing  Application  Software  )  in  C14 

on  Activity  A122  ( Identify  Existing  Data  )  in  C14 

on  Activity  A123  ( Identify  Existing  Technical  Infrastructure  )  in  C14 

on  Activity  A13  (  Define  Reengineering  Project  Plan  )  in  C15 

on  Activity  A133  (  Allocate  Resources  )  in  CIS 

on  Activity  A134  (  Produce  Reengineering  Project  Plan  )  in  CIS 

on  Activity  A131  (  Develop  Reengineering  Strategy  )  in  CIS 

on  Activity  A132  ( Identify  Methodologies  and  Tools  )  in  CIS 

on  Activity  A1 1  (  Define  Objectives  )  in  C17 

on  Activity  Al  1 1  (  Develop  Objectives  &  Success  Factors  )  in  C17 

on  Activity  Al  12  ( Identify  Metrics  )  in  C17 

on  Activity  Al  13  ( Identify  Risks  )  in  CI7 


Transition  Plan  &  Training 

The  Transition  Plan  &  Training  provides  a  plan  to  Implement,  Operate  &  Maintain  the  New  or  Reengineered 
System;  and  to  provide  adequate  training  for  this  transition  to  succeed. 

Usage 

Output  on  Activity  A4  (  Transition  to  Operation  &  Maintenance  )  in  CIS 
Input  on  Activity  AS  ( Implement,  Operate  &  Maintain  )  in  CIS 
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APPENDIX  A  ACRONYMS 


This  Appendix  A  contains  an  alphabetic  listing  of  acronyms  in  this  document.  The  number  in 
parenthesis  following  each  entry  is  the  first  page  number  where  the  acronym  is  used  and 
defined  in  the  document.  The  Model  Glossary  may  also  contain  acronyms  which  are  not 
shown  below  and  are  defined  in  the  text  of  the  Glossary. 
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ACRONYMS 


DISA  (ii)  -  Defense  Information  Systems  Agency 
JIEO  (ii)  -  Joint  Interoperability  Engineering  Organization 
CIM  (ii)  -  Center  for  Information  Management 
CFSW  (ii)  -  Center  for  Software 

OASD  (ii)  -  Office  of  the  Assistant  Secretary  of  Defense 

C^I  (ii)  -  Command,  Control,  Communications,  and  Intelligence 

FFRDC  (ii)  -  Federally  Funded  Research  and  Development  Centers 

DTIC  (iv)  -  Defense  Technical  Information  Center 

AIS  (1-1)  -  Automated  information  system 

IM  (1-1)  -  Information  Management 

FPI  (1-3)  -  Functional  Process  Improvement 

ICAM  (1-5)  -  Integrated  Computer-aided  Manufacturing 

IDEF  (1-5)  -  ICAM  Definition  Language 

IDEFO  (1-5)  -  IDEF  for  function  modeling 
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APPENDIX  B  ICOM  MATRICES 


This  Appendix  B  contains  an  ICOM  Matrix  for  each  diagram  in  the  Model.  The  Matrix 
provides  a  quick  reference  for  identifying  the  inputs,  controls,  outputs,  and  mechanisms  for 
each  activity  on  a  diagram.  The  first  column  in  each  matrix  contains  the  names  of  the 
Concepts.  The  second  column  identifies  the  ICOMs  for  the  parent  activity.  The  subsequent 
columns  identify  the  ICOMS  for  each  lower-level  activity  on  the  diagram. 
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Appendix  B  ICOM  Matrices 


Activities: 

Reengineer  System  (AO) 

Concepts: 

Automated  Information  System 

i 

Available  Reengineering  Technoiogy 

C 

Business  Requirements 

1 

Candidate  Reuse  Assets 

0 

Comp/Comm  Infrastructure 

M 

DoD  Enterprise  Modei 

C 

Feasibiiity  Anaiysis  Resuits 

i 

Methodologies 

M 

Other  Models 

C 

Project  Team 

M 

Recommended  Changes  to  Controls 

O 

Reengineered  System 

0 

Reqs,Poiicy,Stds,Guideiines 

c 

Repositories 

M 

Resource  Limitations 

C 

Reusabie  Assets 

i 

Technical  Architectures 

c 

Toois 

M 
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Activities: 

Define  Project  (A1) 

Reverse  Engineer  {A12) 

Forward  Engineer  (A13) 

Concepts: 

Analysis  Deliverables 

0 

Automated  Information  System 

1 

1 

Available  Reenqineerinq  Technoloqy 

C 

C 

Baselined  AIS  Components 

o 

1 

Business  Requirements 

1 

1 

1 

1 

Candidate  Reuse  Assets 

O 

0 

0 

0 

Comp/Comm  Infrastructure 

M 

M 

M 

M 

DoD  Enterprise  Model 

_ L 

c 

C 

C 

Feasibility  Analysis 

1 

1 

Methodoloqies 

M 

M 

M 

M 

Other  Models 

C 

C 

C 

C 

Proiect  Team 

M 

M 

M 

M 

Recommended  Chanqes 

O 

0 

O 

0 

Reenqineered  System 

O 

O 

Reenqineerinq  Project  Plan 

0 

C 

c 

Reqs,  Policy, Stds, Guidelines 

C 

c 

c 

c 

Repositories 

M 

M 

M 

M 

Resource  Limitations 

C 

c 

Reusable  Assets 

1 

1 

1 

1 

Reverse  Enqineered  Products 

1 

o 

1 

Technical  Architectures 

c 

c 

c 

Tools 

M 

M 

M 

M 
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Activities: 

Define  Objectives  (A1 1 ) 

Identify  Baseline  (A12) 

Define  Reengineering  Project  Plan  (A123) 

Concepts: 

Analysis  Del.,  Rev  Eng  Products 

1 

Analysis  Deliverables 

1 

0 

Automated  Information  System 

1 

1 

1 

Available  Reengineering  Technology 

C 

C 

C 

C 

Baselined  AIS  Components 

O 

O 

1 

Business  Requirements 

1 

1 

1 

1 

Candidate  Reuse  Assets 

o 

O 

0 

O 

Comp/Comm  Infrastructure 

M 

M 

DoD  Enterprise  Model 

C 

C 

c 

Feasibility  Analysis 

1 

1 

1 

1 

Methodologies 

M 

M 

M 

Metrics 

0 

Metrics, Obiectives, Risks 

1 

Obiectives 

0 

c 

Other  Models 

C 

C 

c 

Prelect  Team 

M 

M 

M 

M 

Recommended  Changes  to  Baseline 

1 

o 

Recommended  Changes  to  Controls 

O 

o 

Recommended  Changes  to  Objectives 

1 

o 

Reengineered  System 

O 

C 

o 

Reengineering  Project  Plan 

o 

0 

Regs,  Policy, Stds, Guidelines 

c 

c 

c 

Repositories 

M 

M 

M 

M 

Resource  Limitations 

c 

C 

c 

Reusable  Assets 

1 

1 

1 

Reverse  Engineered  Products 

1 

Risks 

0 

Technical  Architectures 

c 

C 

c 

Tools 

M 

M 

M 

M 
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Activities: 

Develop  Objectives  &  Success  Factors  (At  1 1) 

Identify  Metrics  (At  12) 

Identify  Risks  (A1 13) 

Concepts: 

Automated  Information  System 

1 

1 

Available  Reenqineerinq  Technoloqy 

C 

C 

C 

C 

Business  Requirements 

1 

1 

Candidate  Reuse  Assets 

O 

O 

O 

O 

Comp/Comm  Infrastructure 

M 

M 

M 

M 

DoD  Enterprise  Modei 

C 

C 

Feasibility  Anaiysis 

1 

i 

Methodoioqies 

M 

M 

M 

M 

Metrics 

O 

0 

Objectives 

O 

0 

1 

i 

Other  Modeis 

C 

C 

Project  Team 

M 

M 

M 

M 

Recommended  Changes 

1 

i 

Reos.Poiicv.Stds.Gujdeijnes 

C 

C 

C 

C 

Repositories 

M 

M 

M 

M 

Resource  Limitations 

C 

C 

C 

C 

Reusabie  Assets 

1 

1 

1 

i 

Risks 

O 

O 

Technical  Architectures 

C 

c 

C 

Toois 

M 

M 

M 

M 
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Activities: 

Develop  Reengineering  Strategy  (A131) 

Identify  Methodologies  and  Tools  (At  32) 

Allocate  Resources  (A133) 

Produce  Reengineering  Project  Plan  (At 34) 

Concepts: 

Analysis  Del.,  Rev  Enq  Products 

1 

1 

Available  Reenqineer  Technology 

C 

C 

Baselined  AIS  Components 

1 

C 

C 

Business  Requirements 

1 

I 

Candidate  Reuse  Assets 

o 

O 

O 

DoD  Enterprise  Model 

c 

C 

Feasibility  Analysis 

1 

1 

1 

I 

I 

Metrics, Obiectives, Risks 

1 

1 

1 

I 

Other  Models 

c 

C 

Project  Team 

M 

M 

M 

M 

M 

Proposed  Methodloqie 

1 

O 

I 

Recommended  Changes  to  Baseline 

L  0  1 

0 

O 

0 

Recommended  Changes  to  Controls 

0 

0 

Recommended  Changes  to  Objectives 

0 

o 

Reengineering  Project  Plan 

0 

0 

Reengineering  Project  Strategy 

0 

c 

I 

I 

Regs, Policy, Stds, Guidelines 

c 

c 

Repositories 

M 

M 

M 

M 

Resource  Limitations 

c 

C 

Reusable  Assets 

1 

1 

1 

I 

Revision  to  Project 

I 

Revision  to  Proposed  Methodologies  and  Tools 

1 

Revision  to  Reengineering  Strategy 

1 

Revisions  to  Project  Resources 

o 

Technical  Architectures 

c 

C 

Tools 

M 

M 

M 

M 

M 
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Activities; 

Analyze  Documentation  (A21) 

Analyze  Data  (A22) 

Analyze  Application  Software  (A23) 

Analyze  Technical  Infrastructure  (A24) 

Reconcile  Extracted  Products  (A25) 

Concepts: 

Baselined  AIS  Components 

1 

1 

1 

1 

1 

Business  Requirements 

1 

1 

Candidate  Reuse  Assets 

O 

O 

Comp/Comm  Infrastructure 

M 

M 

DoD  Enterprise  Model 

C 

C 

C 

C 

C 

C 

Feasibility  Analysis 

Extracted  Data  Products 

O 

1 

Extracted  Documentation  Products 

0 

1 

Extracted  Software  Products 

O 

1 

Extracted  Technical  Infrastructure  Products 

0 

1 

Methodologies 

M 

M 

M 

M 

Other  Models 

C 

C 

C 

C 

C 

c 

ProiectTeam 

M 

M 

M 

M 

M 

M 

Recommended  Changes  to  Controls 

0 

0 

Recommended  Product  Reyisions 

1 

1 

1 

1 

0 

Reengineering  Project  Plan 

C 

C 

C 

C 

C 

c 

Regs, Policy, Stds, Guidelines 

C 

C 

C 

C 

C 

c 

Repositories 

M 

M 

M 

M 

M 

Resource  Limitations 

M 

M 

M 

M 

M 

M 

Reusable  Assets 

1 

1 

1 

Reverse  Engineered  Products 

O 

0 

Tools 

M 

M 

M 

M 

M 

M 

B-9 


Appendix  B  ICOM  Matrices 


Activities: 

Analyze  {A31 ) 

Design  (A32) 

Build  (A33) 

Integrate  (A34) 

Test  (A35) 

Concepts: 

Analysis  Deliverables 

O 

O 

O 

O 

O 

0 

Automated  Information  System 

Build  Components 

0 

1 

1 

Build  Results 

1 

o 

Business  Requirements 

1 

1 

Candidate  Reuse  Assets 

1 

1 

1 

1 

1 

1 

Como/Comm  Infrastructure 

o 

o 

O 

o 

0 

O 

Desiqn  Components 

O 

1 

Desiqn  Results 

_ _ 

1 

O 

DoD  Enterprise  Model 

M 

M 

M 

Inteqrated  Component 

O 

1 

Inteqration  Results 

— 

1 

o 

Feasibility  Analysis 

_ 

Methodologies 

M 

M 

M 

M 

M 

M 

Other  Models 

C 

C 

Proiect  Team 

M 

M 

M 

M 

M 

M 

Recommended  Changes  to  Controls 

O 

0 

0 

O 

0 

O 

Reengineered  System 

O 

0 

Reengineering  Proiect  Plan 

C 

C 

c 

c 

c 

c 

Regs,  Policy, Stds, Guidelines 

C 

C 

c 

c 

c 

c 

Repositories 

M 

M 

M 

M 

M 

M 

Resource  Limitations 

Reusable  Assets 

1 

1 

1 

1 

1 

1 

Reverse  Engineered  Products 

1 

1 

1 

Technical  Architectures 

C 

c 

c 

Test  Results 

1 

1 

1 

1 

0 

Tools 

M 

M 

M 

M 

M 

M 
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